Hur skapar du ett lösenord för att hålla ditt SAP-system säkert?

Ett gammalt ämne, lika gammalt som en utsliten jacka efter tvåhundra säkerhetsmöten. Ett ämne lika bekant som det mest populära lösenordet på webben (123456(?)). Ett ämne som redan är lika uttänjt som... ett tunt lager smör på en stor brödskiva... Men det återkommer som en bumerang och inte för att det är populärt och omtyckt, utan för att det är viktigt och kritiskt för säkerheten.

Hur skapar vi oftast lösenord?

Föreställ dig ett scenario där SAP-kärnans inställningar för lösenordsparametrar är standard.

Användaren anger sitt nya lösenord: a.
Meddelandet lyder:  ‘Lösenordet är inte tillräckligt långt (minsta längd: 6 tecken).’

Användaren anger ett nytt lösenord: aaaaaa.
Ett annat budskap ljuder: ‘De tre första tecknen i lösenordet måste skilja sig från varandra.’

Användaren sa: ababab.

Äntligen!

Både användaren är nöjd eftersom systemet har slutat göra livet svårt för honom och systemet är „nöjt”.
Frågan uppstår nu (och om den inte gör det, borde den göra det):

Är en sådan säkerhet tillräcklig för oss som systemadministratörer?

Längden har betydelse

Vad finns det att säga. Ju längre lösenord, desto bättre. Denna regel bryts dock medvetet eller ignoreras helt enkelt, eftersom användaren bagatelliserar användningen av långa lösenord. Det måste vara kort, snabbt och rakt på sak.
Vad kan man göra för att „motivera” användarna att använda längre lösenord, men å andra sidan inte „plåga” dem med att skriva in 40 tecken?
Ändra standardvärdet för parametern ‘inloggning/min_lösenord_lng’.
Vilket värde ska du välja? Minst 12 tecken.
Parametern tillåter ett intervall från 3 till 40 tecken. I extrema fall från 0 till 8 tecken i kombination med en annan parameter.
Kom dock ihåg att ju längre lösenordet är, desto säkrare är det.

Kraften i en slogan

Som det framgick senare i texten tvivlar vi inte på att ett långt lösenord inte är allt.
Användaren anger ett nytt lösenord och måste den här gången „klistra in” minst 12 tecken: abababababab.
När vi tittar på det nya lösenordet drar vi slutsatsen att vår användare lyckligtvis är en fiktiv karaktär och att alla likheter med verkliga användare är slumpmässiga.

Vad kan vi som administratörer göra åt det?

Vi har ytterligare tre parametrar till vårt förfogande:

inloggning/min_lösenord_siffror

inloggning/min_lösenord_bokstäver

inloggning/min_lösenord_special

Den första parametern definierar det minsta antal siffror (siffror från 0 till 9) som användaren måste använda när han eller hon anger ett nytt lösenord. Det kan vara upp till 40, men i kombination med de andra två parametrarna är det maximala antalet 36 siffror.

Den andra parametern tvingar fram ett minsta antal bokstäver som ska anges, återigen upp till 40 tecken (A till Z; a till z). Då återstår specialtecknen. Vad är trots allt ett starkt lösenord utan semikolon eller parentes 😉 Men till saken, vi har något att visa upp med hjälp av de tillgängliga specialtecknen, som inte kommer att vara bokstäver och siffror:

!”@ $%&/()=?’`*+~#-_.,;:{[]}\|

Vi har utvecklat en robust uppsättning tecken som hjälper till att säkra systemet. Trots allt, lösenordet: il1k3indianaj0nes;) är redan verkligen något som är svårare att bryta.

Lösenordskvalitet

Vad sägs om att lägga till spisen och höja kvaliteten på lösenorden? Kan du göra det? Ja, det kan du!

Räddningen är att lägga till två parametrar, vars namn snabbt visar vad sorten handlar om:

inloggning/min_lösenord_låg bokstav

inloggning/min_lösenord_uppercase

Parameter one ansvarar för det minsta antalet gemena bokstäver i ett lösenord.
Det senare gäller det minsta antalet versaler i ett lösenord.

Nu är det magi! En nöjd användare skriver in lösenordet enligt de nya reglerna: A9#CgeGG8ea].

Administratörer glada. Bara... hur kommer man ihåg det...?

Finns det något annat vi kan göra?

Ja. Det är värt att överväga ytterligare säkerhetshöjande parametrar som stöder de som anges ovan.

Säkert vill administratörerna att förändringarna ska träda i kraft, om inte omedelbart så lite senare.

Parameter ‘login/password_compliance_to_current_policy’ är viktigt i sammanhanget, eftersom det tvingar lösenordet att ändras enligt den nya policyn omedelbart efter inloggning.
Om en parameter har värdet 1 innebär det att användarens lösenord kommer att kontrolleras mot den aktuella säkerhetspolicyn för lösenord. Om minst en av parametrarna inte uppfylls kommer ett lösenordsbyte att tvingas fram.

För att lättare komma ihåg lösenord använder många användare egna mallar. När det är dags att ändra lösenordet byter de sedan ut ett eller två tecken. Det innebär att kärnan, eller en stor del av lösenordet, förblir oförändrat.

För att göra sådana åtgärder svårare och hålla lösenordets komplexitet hög kan vi använda parametern ‘inloggning/min_lösenord_diff’. Parameterns värde (från 1 till 40) anger hur många tecken i det nya lösenordet i förhållande till det gamla lösenordet som måste ändras.

En relaterad fråga till ovanstående är att användaren inte bör använda samma lösenord alltför ofta. Detta garanteras av parametern ‘inloggning/lösenord_historik_storlek’. Den lagrar från 1 till de 100 senaste lösenorden som användaren har använt. Om vi ställer in parametern på 5 innebär det att det måste gå fem cykler innan användaren kan använda lösenord nummer 1 igen.

Rekommendation

Implementera. Lämna inte dörren öppen för någon som bara vill komma in i systemet. Kom ihåg att tester bör utföras innan en lösning implementeras, särskilt om ditt system ansluter till system med lägre versioner.
Vem skulle vilja ha ett blockerat produktionssystem? Hand i hand.

Och viktigast av alltAnvändare får inte skriva lösenord på papperslappar och klistra fast dem på bildskärmen, ha dem i datorväskan eller lämna dem på skrivbordet. Det är ju som att skrapa ut/skära/gnugga bort PIN-koden på betalkortet i den bankomat vi använder. En sådan användare bör förmanas.