Av Nils Krumrey, Enterprise Presales Engineer, LogPoint

Våra kunders viktigaste krav är ofta ”logghantering”. Det låter ganska okomplicerat. Men om du vill göra mer än att kryssa i en ruta är det värt att fördjupa dig i vad logghantering egentligen innebär.

Vad innebär loggning?

Alla typer av temporala händelsedata är en logg. Traditionellt sett betraktar vi loggar som långa och komplicerade textfiler, men dagens loggar kan komma från praktiskt taget var som helst och i vilket format som helst. En virusskanner som registrerar klientuppdateringar i sin databas? Det är en logg. Nätverkstrafik från ett virtuellt privat moln i AWS? Det är också en logg. Självklart så finns det vanligt förekommande loggkällor som Windows händelseloggar, webbserverloggar, filåtkomstloggar osv.

Vad är logghantering?

Om det finns loggar, varför behöver de hanteras? Begreppet ”logghantering” kommer från en tid då loggar huvudsakligen bestod av textfiler och administratörer behövde brottas med lagringsutrymme när log99 började om från log00. Det var då loggar behövde ”städas undan” för att ge andningsrum åt källsystemet.

Medan textfiler så småningom har blivit ersatta av Syslog, API:er och databaser är log00-exemplet fortfarande utgångspunkten för logghantering. Kanske inte vad gäller lagringsutrymme utan för att loggarna registreras innan de försvinner. Det är förvånande hur många system som fortfarande skriver över sina loggar och hur snabbt de gör det. Ofta existerar loggar endast i 24 timmar eller kortare tid innan de skrivs över och försvinner. För att kunna tolka dessa data i efterhand måste vi se till att de samlas in och inte går förlorade.

De olika stegen i logghantering

Vi har fastställt vad loggmeddelanden är och varför de ska registreras – men hur gör man det i praktiken?

Logginsamling

Först måste loggmeddelandet samlas in. Antingen måste det hämtas (lösningen hämtar det) eller så måste något det överlämnas till logghanteringslösningen (lösningen samlar in det). Logginsamling kan genomföras för genuina loggfiler genom att logga in på ett system och hämta dem med SCP eller SFTP. Alternativt kan källsystemet konfigureras så att det regelbundet överför loggfiler med lösningens inbyggda FTP-server. Förutom filer kan det handla om Syslog-data (vanligen för nätverksenheter) eller SNMP-fällor. På Windows-baserade system kan det vara en agent, en Windows Event Forwarding Collector eller WMI. Det kan vara ODBC för databaser. Office 365 Management API eller Defender Alert API eller EventHubs API. En s.k. S3 bucket.

Logginsamlingsmetoderna är i själva verket oändliga. Men det är viktigt att logghanteringslösningen stödjer de plattformar och tekniker som du använder för att generera loggdata. Annars kommer det att finnas döda vinklar.

Centraliserad loggaggregering

Ett skäl till att samla in loggar är att säkerställa att de finns tillgängliga på en säker lagringsplats som är lättåtkomlig. Det finns ingen vits med att ha loggfiler utspridda i olika kataloger. Centraliserad loggaggregering är därför ett snabbt sätt att få ut ett värde från loggar. Du måste veta var de finns och hur du får tillgång till dem när de behövs.

Den valda lösningen måste driftsättas effektivt och utan extra kostnader i distribuerade miljöer. En webbplats kan till exempel producera ett överraskande antal loggmeddelanden som överbelastar WAN-länken. Och på vissa molnplattformar kan även generering och nedladdning av loggar ge höga kostnader. I sådana fall kan det vara avgörande att ha loggar lagrade lokalt eller så att de kan genomsökas på distans via en central analysfunktion som t.ex. LogPoint Search Head. Återigen bör lösningen vara tillräckligt flexibel för att kunna anpassas till dina behov och din miljö.

Långtidslagring, sparande av loggar och loggrotation

Ett beslut som alla kunder måste fatta är hur länge loggmeddelanden ska lagras. Här finns ett antal olika saker att tänka på:

  • Efterlevnad: finns det några lagstadgade skäl till att loggmeddelanden måste sparas eller raderas? Här kan PCI, GDPR och företagspolicy gälla. Det kan omfattar data som behöver sparas och data som behöver raderas. Väldefinierade regler för sparande av loggar är fördelaktigt. Vissa loggmeddelanden kanske innehåller personligt identifierbar information som ska sparas under en kortare tid eller så bör vissa av deras fält krypteras.

 

  • Operativa behov: finns det vissa användningsfall där det vore fördelaktigt att ha tillgång till loggmeddelandet i efterhand? Exempel: Efter hur lång tid efter händelsen är det realistiskt (eller juridiskt sett) att en tredje part gör en upphovsrättslig anmälan mot en student som har laddat ner filmer illegalt via ett universitetsnätverk?

 

  • Loggvolymer och kostnader: loggmeddelanden tar upp lagringsutrymme och lagring kostar pengar. Vissa leverantörer debiterar till och med för mängden data som lagras med hjälp deras verktyg. Det ger en specifik kostnad för varje dag som loggmeddelanden lagras och bevaras. I slutänden kommer det till en punkt där kostnaden för att spara loggar under längre tid överstiger fördelarna som de kan ge. Då bör de förmodligen raderas.

Välja rätt lagringslösning för logghantering

När det gäller lagring av själva loggfilerna finns det olika sätt att hantera dem. Vissa molnbaserade och hanterade tjänster inkluderar alla lagringskostnader i abonnemangspriset. Långvarig lagring har dock en tendens att bli dyr. Och det finns inte mycket kontroll över vad som lagras var och hur länge, i och med att data lämnar kundens ägarskap.

Med andra lösningar ägs data av kunderna som driftsätter sina egna lagringsnivåer. Beroende på arkitekturen kan lösningen vara att automatiskt flytta äldre data till en långsammare lagringsnivå (t.ex. en långsammare diskbaserad NAS i stället för DAS/SAN och SSD). Vissa leverantörer skickar loggdata till en offline- eller ”arkivnivå”. Då går återställningsprocessen långsamt när du väl behöver tillgång till de gamla loggarna.

I regel ger en flexibel lösning bäst kontroll över lagring av loggar och kostnader. Att behålla ägarskapet av data, lagra loggmeddelanden under olika tidsperioder, skydda känsliga data samtidigt som de kan genomsökas och låta lösningen hantera lagringsnivåerna automatiskt bör undanröja de flesta utmaningarna i samband med en oflexibel logghanteringslösning.

Logganalys, loggsökning och rapportering – Varför ska du använda logghantering?

Så var står vi nu? Vi har samlat in loggar och sett till att de lagras centralt och under rätt tid. Men efter allt detta arbete vore det logiskt att faktiskt kunna använda dem för något!

I detta läge övergår logghantering till SIEM Security Information and Event Management). Medan säkerhet är ett viktigt fokusområde kan en SIEM-lösning söka efter alla händelser i loggfiler, larma och visualisera händelser via dashboards och rapporter.

Därför är insamling och lagring av loggar ett viktigt första steg. Ibland är insamling och lagring av loggar allt som behövs för att uppfylla vissa efterlevnadskrav. Men det verkliga värdet kommer från allt det du kan göra med loggarna. Exempelvis logganalyser.

Med en SIEM-lösning får du åtkomst till all information i loggarna. Alla loggmeddelanden finns tillgängliga centralt praktiskt taget omedelbart. Det betyder att du alltid vet var du ska felsöka. Oavsett om det handlar om nätverksproblem, virusvarningar, användare som ständigt spärrar sig själva och andra frågor som annars skulle kräva manuell genomsökning av svårtolkade loggfiler från en mängd olika system – förutsatt att de fortfarande vore tillgängliga.

Om du vill ha ännu mer avancerade funktioner som sträcker sig bortom logghanteringsverktygen bör du läsa våra andra blogginlägg på LogPoints webbplats!

Kontakta LogPoint

Kontakta oss och ta reda på varför ledande varumärken väljer LogPoint:

Kom i kontakt med oss

Läs mer om LogPoint

Boka en LogPoint-demo
Kundfall
Kundrecensioner