Sikr dig mod svindel med auditering

23. august 2023

De seneste par år har vi set forskellige eksempler på, at ansatte i det offentlige har brugt deres adgange til it-systemer til at berige dem selv. Selv hvis man får mistanke om, at den slags sker i ens virksomhed, kan det være meget svært at identificere, hvem der står bag, eller hvor stort omfang det har.

Ved at gemme data til senere auditering, kan du nemt spore og identificere mistænkelige aktiviteter og sikre, at der bliver truffet passende foranstaltninger for at håndtere situationen.

Af Dennis Reinholdt Christensen, Senior Software Engineer

Indfang data i et distribueret landskab

For nemt at kunne spore og identificere mistænkelige aktiviteter, kan du implementere et auditeringssystem, som kan opsnappe og arkivere data, der flyder igennem de forskellige it-systemer.

Semler Gruppen, der er Danmarks største bilaktør, er et eksempel på en virksomhed, der ønskede at sikre bedre kontrol af deres data i forbindelse med en større digital transformation af deres forretning.

Derfor skabte vi en en auditeringsløsning, der var tilpasset deres specifikke behov. For at begrænse omkostninger og sikre kontrol over data og funktionalitet, faldt valget på en løsning, baseret på Azure-ressourcer. I normale logging-systemer vil du typisk fokusere på metadata og kun undtagelsesvis medtage applikationsdata - for auditeringssystemet er formålet derimod at gemme både meta- og applikationsdata.

Ved at medtage begge typer data, bliver det muligt at monitorere og analysere data fra flere systemer og kilder hele vejen fra start til slut.

Nedenfor ser du et overordnet diagram over dataflowet i løsningen. Data bliver fanget på vej ind i, eller ud af, en microservice. Disse data kører gennem en Azure Event Hub, hvorfra det behandles af en Azure Function. Function’en sørger for at lagre de rå data, men gemmer også data i indekseret form. Begge dele bliver gemt i Azure Data Lake. I den indekserede data kan vi herefter lave søgninger med Azure Synapse Analytics.

For at kunne skabe et overblik over løsningen, er det nødvendigt at give en kort intro til det digitale landskab, som vi arbejder med hos Semler. Her har vi bygget en integrationsløsning, der baserer sig på en microservicearkitektur. Microservicearkitektur er en softwarearkitektur, der deler en applikation op i mindre, uafhængige tjenester - kaldet microservices - der kommunikerer med hinanden via API'er.

Når man har mange services, har man mange API’er. I løsningen har vi også en række forskellige typer API’er.

Her er fire eksempler, hvor de to første er klart mest udbredt:

HTTP – typisk RESTful
Azure Service bus
Delt blob storage
Delt SQL database

I Semler Gruppens auditeringsløsning vil de gerne fange data, når de bevæger sig over et API, og derfor har vi bygget en generel komponent til hver type API, som er simpel for den enkelte løsning at implementere. De generelle komponenter hjælper også med at lave en metadata envelope rundt om det payload, som vi ønsker at gemme til auditering.

Når man skal samle store datamængder fra mange forskellige kilder, er Azure Event Hub et oplagt valg - det er det, den er lavet til. De enkelte services lægger deres data på hubben, hvor de så kan ligge indtil vores Function har tid til at håndtere dem. Der er rig mulighed for at skalere hubben, så den ikke ender med at være flaskehals. Man kunne også sagtens bruge en anden besked-kø (f.eks. Azure Service Bus), men i forhold til Azures andre værktøjer er Azure Event Hub klart billigst at skalere til store datamængder.

Når beskederne fra hubben skal skrives til Data Lake, er det omkostningerne, der er den primære faktor, man bør være opmærksom på. Azure Data Lake er en billig måde at opbevare store mængder data, men prisen for at skrive til og læse fra Data Laken kan godt eksplodere, hvis man ikke er opmærksom.

Azure Event Hub har en Capture-feature, som gør det muligt at skrive events direkte til Data Lake, men til vores formål er den både for dyr og ikke konfigurerbar nok. I stedet læser vi fra Event Hub med en Azure Function. Functionen opsamler en bunke beskeder fra hubben og skriver dem til Data Lake i deres rå JSON-format. Desuden gemmer den samme data i et indekseret format.

Hvordan fungerer en Event Hub?

Hvis du skal sende beskeder struktureret, skal du bruge en service bus. Men hvis du har rigtig mange beskeder, bliver service bus nemt meget dyrt og så er det værd at overveje at bruge en Event Hub.

Det skyldes for det første at hubben har en højere through-put (både i antal beskeder og i Gigabytes) per krone. Og for det andet skyldes det, at man kan læse fra hubben i batches.

Når en klient læser fra et Event Hub, er det klienten selv, der har et checkpoint. I modsætning til en service bus, ved en hub intet om, hvor mange beskeder klienten har modtaget. Hubben udstiller kun beskederne (de bliver som udgangspunkt liggende en uge) og lader klienten styre, hvor meget, der læses.

Det giver en kontrol som du har brug for, når du arbejder med store datamængder.

Vi har designet et skema til parquet (parquet er et række-kolonneformat a la Excels XLSX-format), som gør det muligt for Synapse at lave søgninger i de gemte data. I dette skema er der blandt andet en kolonne, som indeholder en reference til den fil, hvori den rå data ligger.

Synapse gør det nemt at søge bredt

Det er forventet, at vi skal opbevare auditeringsdataen i fem år. Det fører til datamængder i størrelsesordenen 100 TB. For at kunne opbevare den slags data på en relativt billig måde, er Azure Data Lake en oplagt teknologi.

Dataen bliver gemt både i rå form (det vil ofte være i JSON-format) og i indekseret format. Det indekserede format er CSV. Det gør det muligt lave forespørgsler på data ved hjælp af Azure Synapse Analytics.

Synapse er et meget kraftfuldt værktøj til at håndtere store datamængder, men det er ikke billigt i drift. I hvert fald ikke, hvis det skal søge igennem 100 TB data.

Hvad er Azure Synapse Analytics?

Synapse er en paraply af databehandlingsværktøjer. Det indeholder f.eks. Apache Spark og Azure Data Explorer. Det bliver brugt til at afvikle søgninger i gemte data.

Synapse behandler data ved at opsætte compute clusters som via en map-reduce algoritme tillader at behandle store mængder data på relativ kort tid.

Derfor er det vigtigt:

At der er mulighed for at begrænse den mængde data Synapse behandler. Her lagrer vi data, der gør det muligt at køre på specifikke tidsintervaller.

Ikke at bruge Synapse for meget til forespørgsler. Auditeringsløsningen er designet til at gemme en masse data, som kun skal bruges i særlige situationer, og derfor er Synapse det oplagte valg – fordi søgninger vil være en sjældenhed.

Skræddersyet løsning giver kontrol over indekserede data

Implementeringen af et auditeringssystem er ikke en let opgave, da der kræves en høj grad af kontrol over data for at opnå pålidelighed og effektivitet.

En løsning, der i så høj grad som muligt, bruger off-the-shelf-komponenter kunne f.eks. bruge Azures loggingværktøj lavet på Application Insights. Application Insights giver mulighed for at lave automatisk logning, men for at opsamle den slags payload-data, som Semler har ønsket, ville det kræve omfattende konfigurering og man slipper ikke for at indsætte custom loggingudtryk i koden.

Derefter løber du ind i seriøse problemer med at holde omkostningerne for ingestion og opbevaring nede. Application Insights giver mulighed for at køre komplekse forespørgsler på den lagrede data, men det er alt for dyrt, hvis der er meget data.

Selvom det kan være fristende at ty til standardsystemer, kan de ofte ikke tilbyde den nødvendige kontrol og fleksibilitet til at håndtere komplekse datastrukturer, og det bliver nemt mindst lige så komplekst som en skræddersyet løsning.

Det er vigtigt at tage højde for specifikke behov og udvikle et auditeringssystem, der kan håndtere de unikke krav og udfordringer, som virksomheden står overfor. Det giver også en større fleksibilitet, der gør det nemmere at ændre i systemet, efter man er blevet klogere af at bruge det.

Med et pålideligt og effektivt auditeringssystem på plads kan virksomheder opnå en høj grad af tillid og sikkerhed i deres datastyring, samtidig med, at de overholder de nødvendige standarder og reguleringer. Der er ingen tvivl om, at implementeringen af et sådant system kan være en udfordring, men det er en investering, der betaler sig i det lange løb.

Om Dennis Christensen

Dennis Christensen er Senior Software Engineer og har været en del af Immeo siden 2019. Han arbejdede med noget så gammeldags som mainframe inden han kom til Immeo. Her har han arbejdet med PIM hos Demant og en integrationsplatform hos Semler.

Når Dennis holder fri, elsker han at spille computerspil, særligt strategispil, hvor han prøver at overtage verdensherredømmet.

Derudover læser han meget om mulighederne og farerne ved kunstig intelligens og gjorde det også i mange år før ChatGPT tog verden med storm.

E: drc@immeo.dk | T: +45 2543 7384

Nysgerrig på mere?

Hvad kan du bruge Infrastructure as code til?

Læs mere

Kan Azure Functions virkelig det?

Læs mere