Temat stary, stary jak wytarta marynarka po dwustu spotkaniach nt. bezpieczeństwa. Temat znany, znany jak najpopularniejsze hasło w sieci (123456(?)). Temat już tak rozciągnięty, jak… cienka warstwa masła na dużej kromce chleba… Powraca jednak jak bumerang i nie dlatego, ze jest popularny i lubiany, ale dlatego, że jest ważny i krytyczny dla bezpieczeństwa.
Wyobraźmy sobie scenariusz, w którym ustawienia jądra systemu SAP, dotyczące parametrów haseł, są domyślnie.
Użytkownik wpisuje swoje nowe hasło: a.
Komunikat brzmi: ‘Hasło nie jest wystarczająco długie (minimalna długość: 6 znaków).’
Użytkownik wpisuje kolejne hasło: aaaaaa.
Kolejny komunikat wybrzmiewa: ‘Pierwsze trzy znaki hasła muszą się od siebie różnić.’
Użytkownik na to: ababab.
Wreszcie!
Zarówno użytkownik jest zadowolony, bo system przestał utrudniać mu życie, jak i system jest „zadowolony”.
Pojawia się teraz pytanie (a jeśli się nie pojawia, to powinno):
Czy nam, jako administratorom systemu, wystarczy takie zabezpieczenie?
Co tu dużo pisać. Hasło im dłuższe, tym lepsze. Niemniej zasada ta jest świadomie łamana lub po prostu ignorowana, gdyż użytkownik bagatelizuje używanie długich haseł. Ma być krótko, szybko i do pracy.
Co zrobić, aby użytkownika „zmotywować” do używania dłuższych haseł, ale z drugiej strony nie „zadręczyć” go monotonią wpisywania 40 znaków?
Zmienić domyślną wartość parametru ‘login/min_password_lng’.
Jaką wartość wybrać? Przynajmniej 12 znaków.
Parametr pozwala na zakres od 3 do 40 znaków. W skrajnych przypadkach od 0 do 8 znaków w kombinacji z innym parametrem.
Pamiętajmy jednak, im dłuższe hasło, tym bezpieczniejsze.
Ponieważ pojawiła się w dalszej część tekstu, nie mamy wątpliwości, że długie hasło to nie wszystko.
Użytkownik wpisuje nowe hasło, gdzie tym razem musi „wklepać” minimum 12 znaków: abababababab.
Patrząc na nowe hasło stwierdzamy, że na szczęście nasz użytkownik jest postacią fikcyjną i wszelakie podobieństwo z prawdziwymi użytkownikami jest przypadkowe.
Co jako administratorzy możemy z tym zrobić?
Mamy do dyspozycji kolejne trzy parametry:
login/min_password_digits
login/min_password_letters
login/min_password_specials
Pierwszy z parametrów definiuje nam minimalną liczbę cyfr (cyfry od 0 do 9), którą użytkownik musi użyć wpisując nowe hasło. Może być ich nawet 40, jednak w połączeniu z pozostałymi dwoma parametrami maksimum to 36 cyfr.
Drugi parametr wymusza wpisanie minimalnej liczby liter, znów do 40 znaków (od A do Z; od a do z). Pozostają specjalne znaki. Przecież cóż to za silne hasło bez średnika lub nawiasu 😉 Ale do rzeczy, mamy czym się popisać używając dostępnych znaków specjalnych, które to nie będą literami oraz cyframi:
!"@ $%&/()=?'`*+~#-_.,;:{[]}\<>|
Uszykował nam się solidny zestaw znaków, który pomoże zabezpieczyć system. Przecież hasło: il1k3indianaj0nes;) jest już naprawdę czymś trudniejszym do złamania.
A gdyby tak jeszcze dorzucić do pieca i podnieść jakość haseł? Da się? Da się!
Z pomocą przychodzą dodatki w postaci dwóch parametrów, których nazwy na pierwszy rzut oka wskazują na czym polega urozmaicenie:
login/min_password_lowercase
login/min_password_uppercase
Parametr pierwszy odpowiada za minimalną liczbę małych liter w haśle.
Ten drugi za minimalną liczbę wielkich liter w haśle.
Teraz to dopiero magia! Zadowolony użytkownik wpisuje hasło na nowych zasadach: A9#CgeGG8ea].
Administratorzy przeszczęśliwi. Tylko… jak to zapamiętać…?
Tak. Warto rozważyć dodatkowe parametry podnoszące bezpieczeństwo, które wspomagają te wymienione powyżej.
Na pewno administratorzy chcieliby, aby zmiany weszły w życie jeśli nie natychmiast, to tylko odrobinę później.
Parametr ‘login/password_compliance_to_current_policy’ jest o tyle ważny w kontekście powyższych, gdyż wymusza zmianę hasła względem nowej polityki natychmiast po zalogowaniu.
Ustawienie parametru z wartością równą 1 oznacza, że nastąpi sprawdzenie hasła użytkownika względem aktualnej polityki bezpieczeństwa haseł. Jeśli choć jeden z parametrów nie będzie spełniony, nastąpi wymuszenie zmiany hasła.
W celu łatwego zapamiętania haseł, wielu użytkowników korzysta z własnych szablonów. Gdy przychodzi czas zmiany hasła podmieniają wtedy jeden lub dwa znaki. Oznacza to, że rdzeń, czy też spory „kawałek” hasła pozostaje bez zmian.
Aby takie działania utrudnić i utrzymać wysoką złożoność haseł możemy zastosować parametr ‘login/min_password_diff’. Wartość parametru (od 1 do 40) oznacza, ile znaków w nowym haśle względem starego musi zostać zmienionych.
Pokrewnym zagadnieniem do powyższego jest, aby użytkownik nie używał tych samych haseł zbyt często. Taką funkcję gwarantuje nam parametr ‘login/password_history_size’. Przechowuje on od 1 do 100 ostatnich haseł używanych przez użytkownika. Jeśli ustawimy ten parametr na 5, oznacza to, że musi minąć pięć cykli, aby użytkownik znów mógł użyć hasła nr 1.
Wdrożyć. Nie zostawiać drzwi otwartych każdemu, kto tylko chce wejść do systemu. Pamiętajmy, że przed implementacją rozwiązania należy przeprowadzić testy, zwłaszcza, gdy nasz system łączy się z systemami o niższych wersjach.
Kto chciałby skończyć z zablokowanym systemem produkcyjnym? Ręka do góry.
I najważniejsze: użytkownikom nie wolno pisać haseł na kartkach i przylepiać ich do monitorów, nosić w torbie na komputer lub zostawiać na biurku. Przecież to tak, jakby wydrapać/wyryć/nasmarować PIN do karty płatniczej na bankomacie, którego używamy. Takiemu użytkownikowi należy się upomnienie.
Autor: Bartosz /Sast Team Polska/
WARTO PRZECZYTAĆ NA TEMAT BEZPIECZEŃSTWA SAP:
