W artykule "Bezpieczne hasło SAP" przy pomocy parametrów kernela dotyczących złożoności haseł rozbieraliśmy je na części pierwsze.
Wiemy już, jak znacznie podnieść bezpieczeństwo systemów SAP oraz jak „zmotywować” użytkowników do
większej sumienności w tym aspekcie.
Ten artykuł również będzie nawiązywał do haseł, jednak już bardziej pośrednio i w szerszym spektrum.
Zastanowimy się w jaki sposób podnosząc bezpieczeństwo systemu związane z logowaniem możemy pomóc administratorom.
Przecież admini zasługują na odrobinę oddechu wykonując swoje ciężkie i odpowiedzialne zadania, prawda?
Drodzy administratorzy, chcemy pomóc.
CapsLock… jeden z przykładów, który powoduje, że tracimy dostęp do systemu.
Kto nigdy się w ten sposób nie pomylił, niech pierwszy wystąpi o podwyżkę.
Ale gdzie tu bezpieczeństwo? Przecież ktoś się tylko pomylił.
Ano tu, że system ma to gdzieś i traktuje uczciwego, niefrasobliwego użytkownika tak jak włamywacza i wrzuca ich do jednego worka.
Chcesz się włamać? STOP!
Nie umiesz się zalogować? Możesz nabroić 😉 STOP!
Aby ograniczyć liczbę nieprawidłowych logowań ustawiamy ‘login/fails_to_user_lock’ na przykład na wartość 3.
Za każdym razem, gdy logujemy się nieprawidłowo licznik błędnych logowań zwiększa się o jeden, aż do wartości granicznej, w tym przypadku 3.
Następnie konto jest blokowane.
Może nas odblokować administrator, albo sam system dzięki parametrowi ‘login/failed_user_auto_unlock’.
Ustawienie wymienionego parametru na wartość 1 powoduje, że blokada pozostaje tylko na dzień, w którym nastąpiło zablokowanie.
Należy jednak uważać, aby nie „oberwać rykoszetem”, gdyż włamywacz również będzie miał następnego dnia możliwość próby logowania.
Z pomocą przychodzi wtedy Security Audit Log.
Kto nie sprawdza SALa, ten gapa.
No właśnie. Hasła mają swoją długość życia i domyślnie życie to jest tak długie jak życie systemu, chyba że użytkownik zdecyduje się z własnej inicjatywy na zmianę hasła.
Spoglądając na to zagadnienie z punktu widzenia bezpieczeństwa systemu nie zmienianie w ogóle jest niedopuszczalne.
Hasła powinny być regularnie zmieniane (względnie często).
Nie należy jednak popadać w skrajności i maltretować użytkowników codziennymi zmianami (chyba, że wewnętrzna polityka bezpieczeństwa mówi inaczej).
Ustanowić parametr ‘login/password_expiration_time’. Wartość przypisana parametrowi będzie oznaczała liczbę dni, po której użytkownik będzie musiał zmienić hasło od momentu kiedy ustanowił ostatnie.
Kiedy użytkownik otrzymuje nowe konto lub prosi administratora o zmianę hasła na istniejącym koncie, administrator przypisuje do konta hasło inicjalne.
Ten rodzaj haseł również ma swój czas życia i podobnie jak wyżej, domyślnie jest on tak długi jak długo żyje system. Użytkownik logując się na konto z hasłem inicjalnym zmienia je na hasło znane tylko sobie.
Oznacza to, że im szybciej użytkownik zmieni hasło inicjalne tym lepiej i bezpieczniej.
Jak przymusić do zmiany hasła inicjalnego?
Proste. Kolejny parametr ‘login/password_max_idle_initial’.
Wartość parametru, to liczba dni dana użytkownikowi kiedy ma czas na zmianę. Jeśli tego nie zrobi, to klops, konto zostaje zablokowane.
Warto dodać jeszcze jeden ciekawy parametr: ‘login/password_max_idle_productive’.
Jego wartość oznacza liczbę dni, po których produkcyjne hasło (ustanowione przez użytkownika) zostanie unieważnione, gdy nie będzie używane.
Nie pracujesz? BAN.
Logowanie. Użytkownik i hasło. Ognia. Wykonujemy obowiązki na systemie. Wylogowanie. Koniec. Do domu.
Wszystko w porządku, prawda? Prawda, jeśli to jeden użytkownik i jedno konto.
Co w przypadku, gdy dwóch użytkowników skorzysta z tego samego konta i logują się jednocześnie na ten sam mandant (klient) w systemie?
Taka sytuacja jest już niestety – niepożądana. Dlaczego? Ano dlatego, że chodzi tutaj o pieniądze, o licencje.
Ilu użytkowników, tyle licencji. Ile licencji, tyle pieniędzy dla producenta oprogramowania.
Chcąc nie chcąc należy tego pilnować, taki biznes.
Aby nie mówić użytkownikom: „Hej, pamiętajcie: logujcie się roztropnie, bo inaczej nas SAP po… kieszeniach kopnie”, ustanawiamy parametr ‘login/disable_multi_gui_login’ na 1 (słownie: jeden). Sprawa załatwiona.
Nadmieńmy, ze mówimy tutaj o produkcji.
W wyjątkowych i kontrolowanych okolicznościach można zezwolić użytkownikom na wielokrotne logowanie poprzez parametr ‘login/multi_login_users’.
Jako wartości podajemy nazwy kont (użytkowników) w systemie, którym będzie wolno „łamać” zasadę wielokrotnego logowania.
Na śpiochów lub takich co stoją w kuchni na kawie może podziałać ‘rdisp/gui_auto_logout’,
zrobią miejsca dla tych co chętnie pracują.
Jedni wiedzą, inni nie. Jedni korzystają, inni nie. Wiedząc o tym, że informacja to klucz do… wielu rzeczy, starajmy się za wiele nie podpowiadać. Zwłaszcza tym, którzy nie muszą lub nie powinni zbyt wiele wiedzieć.
O czym mowa?
O prostym parametrze, ale jakże przyjemnym ‘login/show_detailed_errors’. Ustawiamy oczywiście na wartość 0 (zero).
To by było tyle.
Pamiętajcie: kto wdraża bezpieczeństwo w organizacji, bezpiecznie może spać na delegacji.
Autor: Bartosz /Sast Team Polska/
WARTO PRZECZYTAĆ NA TEMAT BEZPIECZEŃSTWA SAP:
