Migrering till S/4HANA - utmaningar inom säkerhet och behörighet

År 2020 beräknas cirka 30% företag globalt börja använda S4/HANA i produktionen (2018 var det endast 2% av alla företag som använde S4). Jag kommer att diskutera två områden som bör adresseras om vi ska kunna höja (eller bibehålla en hög) säkerhetsnivå för målsystemet - behörigheter och teknisk nivå.

Auktoriseringslager

På grund av det faktum att S/4HANA är en ny lösning från SAP-familjen (och inte bara en utveckling av SAP ERP) - överföringen av behörigheter till en ny miljö kan inte genomföras utan lämplig anpassning (t.ex. vissa behörigheter finns inte i S/4).

Vilka åtgärder bör vidtas för att omvandla bemyndiganden?

Ett beslut måste fattas redan från början - om det för målmiljön räcker att överföra (med lämplig anpassning) de nuvarande rollerna (brown field approach) eller om man måste börja arbeta med en ny uppsättning roller (green field approach). Båda tillvägagångssätten har sina fördelar och nackdelar. Allt beror först och främst på den aktuella nivån på användningen av de givna behörigheterna. Vi vet av erfarenhet att det genomsnittliga värdet av utnyttjandet av förvärvade rättigheter för en genomsnittlig organisation (som har haft SAP i åtminstone flera år) är värden mellan 10-15%. Och det kan innebära att de rollbehörigheter som ges inte är optimala - så valet av tillvägagångssätt måste beräknas (ofta med sådan användningsstatistik är greenfield det bästa tillvägagångssättet).

För tillvägagångssättet brunfält vi använder SAST-verktyg, som stöder omvandlingen av tillstånd till S/4HANA (Visst manuellt arbete krävs). För att testa nya roller - vi håller på att implementera ett verktyg för att underlätta produktionsdistribution av roller (mer om det om en stund).

På väg grönområde arbetar vi med en metod för att skapa risker och roller (baserat på konfliktfria rollmallar avsedda för S/4HANA). Här stödjer vi också produktionstestning av roller.

Det är också nödvändigt att verifiera kritisk tillgång i roller och auktoritetskonflikter, och uppdatering SU24. Generellt sett - utan en omorganisation av tillståndsbegreppet är migration omöjlig.

Säker lansering av roller på produktionssystemet - testning

Allt projektarbete som involverar testanvändare riskerar att leda till förbiseenden. Att skapa nya roller och testa dem före produktionssättning är avgörande för implementeringen av affärsprocesser. Om nya roller inte testas tillräckligt finns det en risk att de inte kan utföra sina uppgifter. Därför har vi infört stöd för detta steg genom att automatisera testprocessen (beviljande, skapande av testanvändare) och implementera möjligheten att återgå till de gamla behörigheterna (fallback-användare).

I praktiken ser det ut så här:

1 - de skapade (och i förväg testade) rollerna fästs på användarna (ersätter de gamla rollerna),

2 - i händelse av att användaren inte kan utföra en åtgärd (inte kan arbeta) - återgår till den gamla uppsättningen roller på nödbasis (detta sker automatiskt, åtgärden tar 1-2 minuter),

3 - administratören får information om användarens aktiviteter som skiljer sig från den nya uppsättningen roller - baserat på detta fattas ett beslut om huruvida nya roller ska läggas till för användaren eller inte.

Använda fallback - aktiviteter i produktionssystemet har ingen nedtid, inte ens i händelse av fel vid skapande/testning av behörighet.

Tekniskt lager

Nya installationer S4 har ett antal risker redan i själva standardkonfigurationen (kunden får därför en uppsättning parametrar att justera för att öka säkerhetsnivån). Risker i målinfrastrukturen S/4HANA kan generellt delas in i två områden: osäker systemkonfiguration och sårbarheter i klientlösningar ABAP.

Vi gör en hel del säkerhetsrevisioner och genomför även penetrationstester. Erfarenheter från sådana projekt bekräftar att de främsta orsakerna till SAP-säkerhetsproblem är

- avsaknad av implementerade säkerhetsriktlinjer (eller avsaknad av patchar),

- brist på separation i nätverket,

- Avsaknad av övervakningsverktyg.

Processmodell för säker migrering till SAP HANA

Verifiering av säkerhetsnivå

1 - verifiera målsystemets säkerhetsnivå (god praxis på SAP:s säkerhetsmarknad är användbar för att identifiera de mest akuta problemen),

2 - Sammanställ de risker som upptäckts i en rapport med information om korrigerande åtgärder,

3 - skapa prioriteringar för risker för att förbättra säkerheten.

Höjning av säkerhetsnivån

Baserat på rapporten, risker och prioriteringar, börja täta miljön. Kom ihåg att lagren under SAP:s applikationslager (OS/net/DB) och klientens ABAP-tillägg (som kan innehålla kritiska funktioner, anrop eller sakna auktoriseringsobjekt) också är viktiga.

Det är viktigt att de som är ansvariga för området är med i arbetet för att bekräfta att förändringarna inte påverkar befintliga processer. En utmaning är utan tvekan klienternas ABAP-program. Organisationer har sällan detaljerade beskrivningar av alla program och lika sällan kunskap om de program som används särskilt mycket. Detta visar sig i det faktum att i ett kluster med flera tusen Zetas är det bara några dussin/några hundra som används i det dagliga arbetet. Det är därför nödvändigt att samla in relevant information om användningen av programmen. Vi identifierar de program som inte används och minimerar risken med en „mjuk rengöringsmetod”. Med detta tillvägagångssätt kan vi minska migrationskostnaderna och själva kodrensningen är 80% snabbare (och billigare) än standardmetoden.

Säkerhetsövervakning

När miljön har förseglats - börja övervaka den. Alla kritiska förändringar i inställningarna bör fångas upp direkt. Och även här gäller detta de lager som är viktiga ur SAP-synpunkt.

Sammanfattning

Oavsett miljöns storlek och omfattning - som en del av migreringen till S/4HANA föreslår vi att man tittar på säkerhetsnivån för målplattformen. I slutändan är det så att ju tidigare säkerhetsproblem upptäcks, desto lägre blir kostnaderna för att lösa dem. Det är upp till organisationen att besluta om nödvändiga steg och riskreducering. Vi kan hjälpa till i varje skede av arbetet med att säkra ert SAP-system.