Jak podnieść bezpieczeństwo systemu związane

z logowaniem?

 

poprzednim artykule 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.

 

Dlaczego tracimy dostęp do systemu?

 

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.

 

Jaka jest długość życia haseł?

 

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).

 

W jaki sposób uszczęśliwić użytkowników, aby żyli ze świadomością,

że ich konta są bezpieczne?

 

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.

 

A jak wygląda kwestia logowania?

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.

wyjątkowychkontrolowanych 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ą.

 

PODSUMOWANIE

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/