Jak podnieść bezpieczeństwo systemu?
Lukardi > Blog > Sicherheit > Jak podnieść bezpieczeństwo systemu?
- Sicherheit
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.
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.
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ą.
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.
Tomasz Jurgielewicz
Head of Security Department w Lukardi. Od 10 lat prowadzi zespół specjalistów SAP Security, dostarczając kompleksowe usługi i narzędzia do zabezpieczenia systemów SAP oraz optymalizacji licencji. Doświadczenie w obszarze: - identyfikacji konfliktów uprawnień i reorganizacji autoryzacji, - identyfikacja podatności SAP, - integracja rozwiązań SIEM z SAP, - optymalizacja licencji SAP.