Av Dmitry Gutsko, SAP Security Expert

Vi vet att SAP-databassystem ofta förbises när det gäller en organisations säkerhetsinfrastruktur. Den är full av datasilon och döda vinklar – och det mest oroväckande är att företagsledningar ofta är medvetna om det. Till exempel är 66 % av företagsledarna oroade över den stigande hotnivån runt om i världen. Och hur är det med insiderhot? Dessa incidenter har ökat med 44 % under de senaste två åren och kostar 15,38 miljoner dollar per incident. Så hur ser framtidens SAP-säkerhet ut?

Just nu har vi s.k. big data. Framtiden innebär ännu större datakällor. Till följd av detta kommer ännu högre krav ställas på att förstå kunder, kunddata och deras behov. Till detta tillkommer den planerade SAP-migreringen som är planerad för 2027 och driver på mot SAP HANA. Forskning som publicerades i mars 2021 tyder på att endast 24 % av alla SAP-kunder redan har genomfört övergången till SAP S/4HANA, medan 23 % uppger att inte har några migreringsplaner.

Låt oss börja där. Just nu är (SAP) S/4HANA inom SAP-säkerhet underskattat, men med tanke med att migreringen kommer att ske om några år är det viktigt att vi förstår de behov, utmaningar och metoder som kan användas.

Vilka är de största utmaningarna för SAP-säkerhetsteam?

  • Hur skyddar man data mot obehörig åtkomst?
  • Hur behåller man kontrollen över administratörer och användare med hög behörighet?
  • Och hur identifierar man skadlig ABAP-kod i SAP-landskapet?

Med detta fastställt, måste vi nu ta reda på hur vi enkelt kan identifiera alla dessa användningsfall med hjälp av endast en loggkälla.

Som du kanske vet finns det ett stort antal SAP-affärsmoduler som bygger på SAP NetWeaver ABAP Platform. Varje modul förser SAP-slutanvändare och SAP-konsulter med en mängd olika funktioner. Självklart kan inte IT-säkerhetsteamet lära sig alla aspekter av varje enskild modul, men de kan istället styra åtkomsten till tabeller med känslig information på databasnivå.

Tabeller och SQL-frågor är välkända begrepp i IT-världen och varje säkerhetsexpert förstår dem. Med en sådan metod behöver du inte längre förlita dig på nya SAP-tekniker som FIORI, SAPUI5 och S/4 HANA. All kod exekverar till slut en SQL-fråga till databastabeller som innehåller data. På så sätt kan vi förena SAP-säkerhetskontroller, oavsett vilken specifik SAP-programvara och teknik du använder. Vi behöver bara styra vilka SQL-förfrågningar som kan göras och vilka tabeller som exekveras på HANA-nivå och av vem. På så vis kan den moderna SIEM-lösningen skilja typiska förfrågningar från avvikande förfrågningar och identifiera illasinnad åtkomst (eller modifiering) till känslig information i SAP.

Skyddet mot administratörer utan säkerhet på HANA-nivå i SAP-programvaran verkar nästan löjligt. Det enklaste sättet för SAP BASIS-experter att läsa löner är att använda HANA Studio, verktyget SAP HANA hdbsql eller DBCOCKPIT. I de flesta fall kommer frågesatser till databaser att hanteras av tekniska SAPABAP1-användare (schemaägare) eller SYSTEM-användare. På så sätt kan de enkelt undkomma upptäckt och oönskade frågor eftersom aktiviteter där tekniska användare har åtkomst till data är typiska.

Vad ska säkerhetsteamet göra i ett sådant fall?

I praktiken finns det bara ett alternativ – att aktivera skydd på SAP HANA-nivå och aktivera loggning för kritiska tabeller även för tekniska HANA-användare (en illasinnad administratör kommer aldrig att använda sina egna användaruppgifter för åtkomst till en SAP HANA-databas).

Det finns många fall där utvecklare och entreprenörer har skapat skadlig ABAP-kod i kunders produktionssystem och sedan exekverat den. Livslängden på sådana program kan vara så lite som fem minuter och vissa ABAP-program kan till och med exekvera dynamisk kod. Därför är det extremt svårt att upptäcka sådan skadlig kod med hjälp av källkodsskannrar. Det kan vara svårt att tro, men även detta användningsfall kan enkelt identifieras med hjälp av HANA-loggar. Oavsett vilken ABAP-kod som infiltratörerna använder (standard eller anpassad) kommer de så småningom att använda en specifik SQL-frågesats för att komma åt och ändra känsliga data. Det kan också avslöja angriparens avsikter och personlighet.

Idag växer antalet SAP HANA-databasanvändare ständigt. I början fick endast administratörer legitim åtkomst till SAP-databasen. Den nuvarande bilden är helt annorlunda. Entreprenörer, utvecklare, SAP-konsulter och även slutanvändare har sina egna användarkonton i en HANA-databas, vilket gör det ännu viktigare att vi kontrollerar användarbehörigheter mer noggrant, samt åtgärder med användarbehörigheter – i synnerhet behörigheter för SAPABAP1 schematabeller.

Vad ska man ta hänsyn till vid säkring av SAP HANA?

Det är viktigt att inte glömma bort modern teknik som kalkyl-/analysvyer i HANA som kan möjliggöra oönskad åtkomst till känsliga data. Likaså växer antalet HANA-till-HANA-integrationer mellan SAP-system ständigt och alla dessa kan skapa potentiella säkerhetshot mot dina data.

Säkerhet på HANA-nivå är avgörande och kommer att bli ännu viktigare i framtiden. HANA-loggar kan hjälpa oss alla att skydda våra SAP-system, men ändå finns det bara ett säkerhetstema inom SAP som är allmänt erkänt i världen – nämligen SoD (Segregation of Duties). ndast ett fåtal driftsätter SIEM-lösningar för att identifiera avvikande beteenden i SAP-system. Ännu färre kunder tänker på skydd på HANA-nivå. Denna situation kommer dock att förändras i takt med att allt fler företag vänder sig till verktyg som Logpoint BCS för SAP som stödjer HANA-loggkällor och kan anslutas till alla SIEM-system. Att skydda dina SAP-landskap har aldrig varit enklare eller mer heltäckande.

Contact Logpoint

Contact us and learn why
industry-leading companies
choose Logpoint:

Contact Logpoint