Bezpieczeństwo panelu administracyjnego: 8 rzeczy do sprawdzenia

Każdy firmowy system z logowaniem to drzwi do danych klientów, faktur i dokumentów. Panel sklepu, CRM, panel strony internetowej: wszystkie stoją w internecie i wszystkie są codziennie odpytywane przez automaty, które szukają słabego hasła albo źle zamkniętego zamka. Bezpieczeństwo panelu administracyjnego nie jest więc tematem dla dużych korporacji, tylko codzienną sprawą każdej firmy, która z takiego panelu korzysta.

Zanim wystawiliśmy do internetu nasz własny panel firmowy, przeszliśmy go pod kątem bezpieczeństwa punkt po punkcie. Poniższa lista wyrosła z tego przeglądu. Możesz przejść ją ze swoim wykonawcą, nawet jeśli nie znasz się na programowaniu, bo każde pytanie da się zadać po ludzku.

Bezpieczeństwo panelu administracyjnego zaczyna się od logowania

1. Limit prób logowania, który naprawdę działa. Panel powinien blokować kolejne próby po kilku nieudanych logowaniach. Diabeł tkwi w szczegółach: jeśli system najpierw sprawdza hasło, a dopiero potem zapisuje próbę, atakujący wysyłający setki prób jednocześnie może prześlizgnąć się ponad limit. Dobrze zrobiony limit najpierw rezerwuje próbę, a dopiero potem sprawdza hasło.

2. Hasła, których nie da się odczytać. W bazie danych nie powinno być haseł, tylko ich skróty utworzone algorytmem zaprojektowanym do tego celu. Nawet gdyby ktoś wykradł bazę, nie odczyta z niej haseł wprost. Zapytaj wykonawcę, jak przechowuje hasła. Jeśli odpowiedź brzmi „w bazie", to zły znak.

3. Sesja, którą da się zamknąć. Kiedy zmieniasz hasło, bo podejrzewasz, że ktoś je poznał, wszystkie inne zalogowane urządzenia powinny zostać wylogowane. Bez tego zmiana hasła niewiele daje, bo intruz z otwartą sesją dalej jest w środku.

Uprawnienia sprawdza serwer, nie przycisk

4. Każda akcja sprawdzana po stronie serwera. To najczęstszy błąd w aplikacjach internetowych. W zestawieniu OWASP Top 10, czyli liście najpoważniejszych zagrożeń dla aplikacji webowych, błędna kontrola dostępu zajęła w 2021 roku pierwsze miejsce. W praktyce wygląda to tak: pracownik nie widzi przycisku „usuń klienta", więc wszyscy zakładają, że nie może tego zrobić. Tymczasem jeśli serwer nie sprawdza uprawnień przy samej operacji, wystarczy wysłać odpowiednie żądanie z pominięciem przycisku. Ukrycie przycisku to wygoda, a nie zabezpieczenie.

5. Integracje z najmniejszymi możliwymi uprawnieniami. Gdy panel łączy się z innymi systemami, dostaje do nich klucze. Te klucze powinny pozwalać tylko na to, czego panel naprawdę potrzebuje. Przykład z naszej praktyki: przy integracji z KSeF system dostaje token wyłącznie do przeglądania faktur. Nie może niczego wystawić ani zmienić uprawnień, więc nawet przejęcie panelu nie pozwoliłoby wysłać faktury w imieniu firmy. Więcej o takich połączeniach pisaliśmy w tekście o tym, jak działa integracja systemów w firmie.

Sekrety i dane wrażliwe

6. Hasła i klucze poza kodem i poza logami. Hasła do skrzynek pocztowych, klucze do sklepu czy do usług zewnętrznych nie powinny leżeć w kodzie aplikacji ani pojawiać się w komunikatach błędów. Komunikat „nie udało się połączyć z kluczem abc123" w dzienniku serwera to wyciek, który czeka na okazję. Dobrze zrobiony panel maskuje takie wartości wszędzie, gdzie mogłyby zostać wyświetlone albo zapisane.

Panel nie może być furtką do sieci wewnętrznej

7. Ostrożność przy adresach podawanych przez użytkownika. Wiele paneli pobiera coś z adresu wskazanego przez użytkownika: importuje dane z linku, sprawdza stronę klienta, pobiera obraz. To wygodne, ale niebezpieczne. Atakujący może podać adres, który prowadzi nie do internetu, tylko do wnętrza serwera albo sieci firmy, i w ten sposób dostać się do usług, które nigdy nie miały być publiczne. Ten typ ataku ma nawet swoją nazwę, SSRF. Obrona polega na sprawdzaniu każdego adresu, także po przekierowaniach, bo pierwsze sprawdzenie łatwo obejść, kierując zapytanie na zewnątrz, a stamtąd z powrotem do środka. Nasz moduł do audytów stron sprawdza każdy adres właśnie w ten sposób.

Kopie i plan na najgorszy dzień

8. Kopie zapasowe poza serwerem, sprawdzone odtworzeniem. Kopia leżąca na tym samym serwerze co panel znika razem z nim przy awarii dysku albo ataku. Kopia musi trafiać w inne miejsce, najlepiej zaszyfrowana. I co najważniejsze: przynajmniej raz trzeba ją faktycznie odtworzyć na próbę. Kopia, której nikt nigdy nie przywrócił, jest tylko nadzieją, że zadziała.

Warto też ustalić z góry, kto decyduje o przywróceniu kopii i ile danych firma może stracić. Kopia z poprzedniej nocy oznacza utratę zmian z całego dnia, a to w firmie, która wystawia wyceny i przyjmuje zamówienia, bywa odczuwalne.

Jak przejść tę listę z wykonawcą

Nie musisz znać się na programowaniu, żeby z tej listy skorzystać. Wystarczy poprosić wykonawcę o krótką, pisemną odpowiedź na każdy z ośmiu punktów. Nie chodzi o wykład, tylko o kilka zdań: jak to jest zrobione i co się dzieje w razie problemu.

Zwróć uwagę na ton odpowiedzi. „Spokojnie, wszystko jest bezpieczne" bez konkretów to sygnał ostrzegawczy. Dobra odpowiedź brzmi raczej tak: „po pięciu nieudanych próbach konto blokuje się na kwadrans", „kopie trafiają co noc do innego centrum danych, ostatnie odtworzenie testowe robiliśmy wtedy i wtedy". Zapytaj też, kto ma dostęp do serwera, na którym działa panel, i co się dzieje z tym dostępem, gdy ktoś przestaje pracować przy projekcie. To pytanie często zaskakuje, a odpowiedź mówi bardzo dużo o tym, jak poważnie wykonawca traktuje dane Twojej firmy.

Co dalej z tą listą

Osiem punktów to nie wszystko. Do pełnego obrazu dochodzą jeszcze regularne aktualizacje bibliotek, szyfrowane połączenie z wymuszonym HTTPS i dziennik zmian, który pokazuje, kto i kiedy zrobił w panelu coś ważnego. Ale jeśli Twój panel przechodzi tych osiem pytań, ma solidne podstawy, na których można budować resztę.

Jeśli masz wrażenie, że Twoja strona albo panel mogły już paść ofiarą ataku, zacznij od wpisu o tym, jak sprawdzić, czy strona jest zainfekowana. A jeśli dopiero planujesz system dla firmy, na stronie o panelu CRM na zamówienie opisaliśmy, jak do tego podchodzimy.