Hur kan man förbättra systemsäkerheten?

Denna artikel kommer också att hänvisa till slogans, men mer indirekt och i ett bredare spektrum.

Vi kommer att överväga hur förbättrad systemsäkerhet i samband med loggning kan hjälpa administratörer.
När allt kommer omkring förtjänar administratörer lite andrum när de gör sina hårda och ansvarsfulla jobb, eller hur?

Kära administratörer, vi vill hjälpa till.

Varför förlorar vi tillgången till systemet?

CapsLock... ett exempel som gör att vi förlorar tillgången till systemet.
Den som aldrig har haft fel på det här sättet borde vara den första att be om löneförhöjning.

Men var finns säkerheten här? Någon har ju trots allt bara gjort ett misstag.

Jo, att systemet inte bryr sig ett dugg och behandlar en ärlig, sorglös användare som en inbrottstjuv och buntar ihop dem.

Vill du bryta dig in? STOPP!

Vet du inte hur du loggar in? Du kan rota runt lite 😉. STOPP!

För att begränsa antalet felaktiga inloggningar ställer vi in ‘login/fails_to_user_lock’ till ett värde av 3, till exempel.
Varje gång vi loggar in felaktigt ökar räknaren för felaktiga inloggningar med en, upp till ett gränsvärde, i det här fallet 3.

Kontot spärras därefter.

Vi kan låsas upp av administratören eller av systemet självt via parametern ‘login/failed_user_auto_unlock’.

Om den nämnda parametern sätts till 1 kommer låset endast att vara kvar under den dag då låsningen inträffade.

Man måste dock vara försiktig så att man inte „studsar tillbaka”, eftersom inbrottstjuven då också har möjlighet att försöka logga in nästa dag.
Det är här Logg för säkerhetsgranskning.

Den som inte kollar SAL är på utkik.

Hur lång är livslängden för lösenord?

Ja, det stämmer. Lösenord har en livslängd och som standard är den livslängden lika lång som systemets livslängd, såvida inte användaren på eget initiativ beslutar att byta lösenord.

Att se på frågan ur systemsäkerhetssynpunkt inte förändras överhuvudtaget är oacceptabelt.

Lösenord bör vara regelbundet ändras (relativt ofta).

Gå dock inte till ytterligheter och misshandla användarna med dagliga ändringar (såvida inte den interna säkerhetspolicyn säger något annat).

Hur gör vi användarna nöjda så att de kan leva i förvissningen om att deras konton är säkra?

Fastställa parametern ‘login/password_expiration_time’. Det värde som parametern tilldelas anger antalet dagar efter vilka användaren kommer att vara måste ha ändra lösenordet sedan han fastställde det förra.

När en användare får ett nytt konto eller ber en administratör att ändra lösenordet för ett befintligt konto, tilldelar administratören ett första lösenord till kontot.
Den här typen av lösenord har också en livslängd och är, som ovan, standardmässigt så länge som systemet lever. En användare som loggar in på ett konto med ett initialt lösenord ändrar det till ett lösenord som bara han eller hon känner till.
Det innebär att ju tidigare användaren ändrar det ursprungliga lösenordet, desto bättre och säkrare är det.

Hur tvingar jag fram en ändring av det ursprungliga lösenordet?

Enkelt. En annan parameter ‘login/password_max_idle_initial’.’.

Värdet på parametern, är det antal dagar som ges till användaren när han har tid att ändra. Om han eller hon inte gör det, sedan klops, kontot är blockerat.

En annan intressant parameter är värd att lägga till: ‘login/password_max_idle_productive’.

Dess värde anger det antal dagar efter vilket produktionslösenordet (som skapats av användaren) kommer att ogiltigförklaras när det inte används.

Fungerar det inte? BAN.

Vad är problemet med att logga in?

Logga in. Användare och lösenord. Brand. Utför arbetsuppgifter på systemet. Logga ut. Avsluta. Hem.

Allt är i sin ordning, eller hur? Det är sant, om det är en användare och ett konto.

Vad händer om två användare använder samma konto och loggar in på samma mandat (klient) i systemet samtidigt?

En sådan situation är redan nu - tyvärr - oönskad. Varför är det så? Jo, därför att det handlar om pengar, om licenser.
Lika många användare, lika många licenser. Hur många licenser, så mycket pengar för programvarutillverkaren.
Vare sig man vill eller inte måste man titta på det, den typen av verksamhet.

För att inte säga till användarna: „Hej, kom ihåg: logga in på ett klokt sätt, annars kommer SAP att sparka oss i ... fickorna”, etablerar vi en parameter ‘login/disable_multi_gui_login’ för 1 (i ord: en). Fallet är avgjort.

Låt oss nämna att vi talar om produktion här.

W unik i kontrollerad är det möjligt att tillåta användare att logga in flera gånger genom parametern ‘login/multi_login_users’.
Namnen på de konton (användare) i systemet som tillåts „bryta” mot regeln om flera inloggningar anges som värden.

För sömniga eller de som står i köket och dricker kaffe kan fungera ‘rdisp/gui_auto_logout’,
kommer att göra plats för dem som är villiga att arbeta.

SAMMANFATTNING

Vissa vet, andra gör det inte. Vissa drar nytta av det, andra inte. Med vetskapen om att information är nyckeln till... många saker, låt oss försöka att inte antyda för mycket. Särskilt inte till dem som inte behöver eller inte bör veta för mycket.

Vad är det vi pratar om?

Om en enkel parameter, men hur trevlig ‘login/show_detailed_errors’. Naturligtvis inställd på 0 (noll).

Det var allt.

Kom ihåg: Den som implementerar säkerhet i en organisation kan sova tryggt på en affärsresa.