Af Dmitry Gutsko, SAP Security Expert

Vi ved, at SAP-databasesystemerne ofte overses, når det kommer til en organisations sikkerhedsinfrastruktur. De er fulde af siloer og blinde vinkler, og det bekymrende er, at ledelsen godt er klar over det. For eksempel er 66 % af lederne bekymrede over det stigende trusselsniveau rundt omkring i verden. Og hvad med insidertrusler? Disse hændelser er steget med 44 % i løbet af de seneste to år og koster $15,38 millioner pr. hændelse. Hvordan ser fremtiden for SAP-sikkerhed så ud?

Lige nu har vi big data. I fremtiden kan vi forvente os endnu større mængder data, og med det følger endnu større krav til forståelsen af kunder, kundedata og deres behov, og så er der den forventede SAP-migrering, der er planlagt til at finde sted i 2027, og som yderligere understreger vigtigheden af SAP HANA. Undersøgelser, der blev offentliggjort i marts 2021, viser, at kun 24 % af SAP-kunderne allerede har foretaget overgangen til SAP S/4HANA, og 23 % angav, at de ikke havde planer om at migrere.

Så lad os begynde der. Lige nu er (SAP) S/4HANA undervurderet inden for SAP-sikkerhed, men nu hvor der kun er nogle få år til migreringen, er det vigtigt, at vi forstår de behov, udfordringer og metoder, der kan bruges.

Hvad er de største udfordringer for SAP-sikkerhedsteams?

  • Hvordan beskyttes data mod uautoriseret adgang?
  • Hvordan bevarer man kontrollen over administratorer og brugere med rettigheder på højt niveau?
  • Og hvordan identificerer du ondsindet ABAP-kode i dit SAP-miljø?

Med det udgangspunkt er vi nu nødt til at finde ud af, hvordan vi nemt kan registrere alle disse use cases ved hjælp af kun én logkilde.

Som I måske ved, er der en lang række SAP-forretningsmoduler, der er baseret på en SAP NetWeaver ABAP-platform. Hvert modul giver SAP-slutbrugere og SAP-konsulenter en masse funktionalitet. Selvfølgelig kan medlemmerne af IT-sikkerhedsteamet ikke lære alle aspekter af hvert enkelt modul at kende, men de kan kontrollere adgangen til tabeller med følsomme oplysninger på databaseniveau i stedet.

Tabeller og SQL-forespørgsler er velkendte termer i IT-verdenen, og alle sikkerhedseksperter ved, hvad det drejer sig om. Hvis du bruger en sådan tilgang, behøver du ikke længere at være afhængig af nye SAP-teknologier som FIORI, SAPUI5 og S/4 HANA. Til sidst udfører enhver kode en SQL-forespørgsel til databasetabeller med data. På den måde kan vi samle SAP-sikkerhedstjek, uanset hvilken specifik SAP-software og -teknologi du bruger. Vi skal kun styre, hvilke SQL-anmodninger der kører, og hvilke tabeller der er udført på HANA-niveau og af hvem. Det sætter det moderne SIEM i stand til at skelne mellem typiske anmodninger og dem, der er unormale, og identificere ondsindet adgang (eller ændring) til følsomme oplysninger i SAP.

Beskyttelsen af SAP-software mod administratorer uden sikkerhed på HANA-niveau ser ærlig talt lidt dumt ud. Den nemmeste måde for SAP BASIS-eksperter at læse løn på er med HANA Studio, SAP HANA hdbsql tool eller DBCOCKPIT. Anmodninger til databaser vil i de fleste tilfælde være under den tekniske SAPABAP1-bruger (skemaejer) eller SYSTEM-bruger. Så de slipper nemt for enhver identifikaiton og uønskede spørgsmål, fordi sådanne aktiviteter, der kommer fra tekniske brugere, der får adgang til dataene, er helt typiske.

Hvad skal sikkerhedsteamet gøre i dette tilfælde?

Grundlæggende er der kun én mulighed – aktivér beskyttelse på SAP HANA-niveau og aktivér logning for kritiske tabeller, selv for tekniske HANA-brugere (en administrator, der har dårlige intentioner, vil aldrig bruge sin egen bruger i SAP HANA-databasen).

Der er mange tilfælde, hvor udviklere og konsulenter opretter en ondsindet ABAP-kode i kundens produktionssystemer og derefter kører den. En levetid for sådanne programmer kan kun være fem minutter, eller selv ABAP-programmer kan udføre dynamisk kode. Derfor er det ekstremt svært at opdage så ondsindet kode ved hjælp af kildekodescannere. Det kan måske være vanskeligt at tro på, men selv denne use case kan nemt detekteres ved hjælp af HANA-logfiler. Uanset hvilken ABAP-kode infiltratorerne bruger (standard eller brugerdefineret) i dette tilfælde, vil de med tiden starte en specifik SQL-anmodning for at få adgang til og ændre følsomme data. Det kan også afsløre angriberens intentioner og personlighed.

I dag vokser antallet af SAP HANA-databasebrugere konstant. I begyndelsen fik kun administratorer legitim adgang til SAP-databasen. Det nuværende billede er helt anderledes. Konsulenter, udviklere, SAP-konsulenter og endda slutbrugere har deres egne brugerkonti i en HANA-database, hvilket gør det endnu vigtigere, at vi kontrollerer brugerrettigheder mere omhyggeligt samt handlinger med brugerrettigheder, især rettigheder for SAPABAP1-skematabeller.

Hvad skal der tages højde for ved sikring af SAP HANA?

Det er vigtigt ikke at glemme moderne teknologier som beregningsvisninger/analysevisninger i HANA, som kan indeholde uønsket adgang til følsomme data. Ligeledes vokser antallet af HANA-til-HANA-integrationer mellem SAP-systemer konstant, og alle disse kan generere mulige sikkerhedstrusler mod dine data.

Sikkerhed på HANA-niveau er afgørende og vil blive endnu vigtigere i fremtiden. HANA-logfiler kan hjælpe os alle med at beskytte vores SAP-systemer, alligevel er der kun et enkelt SAP-sikkerhedsemne, der er almindeligt anerkendt i verden – SoD (Segregation of Duties). Kun få implementerer SIEM-løsninger og forsøger at registrere unormal adfærd i SAP-systemer. Endnu færre kunder tænker på beskyttelse på HANA-niveau. Denne situation vil dog ændre sig, efterhånden som flere og flere virksomheder vælger at benytte værktøjer som Logpoint BCS til SAP, der understøtter HANA-logkilden, og som kan integreres med ethvert SIEM. Det har faktisk aldrig været nemmere eller mere omfattende at beskytte dine SAP-miljøer.

Contact Logpoint

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

Contact Logpoint