Af Nils Krumrey, Enterprise Presales Engineer, LogPoint

Når kunder taler til os, er det første krav på deres liste ofte “log management”. Det lyder rimeligt ligetil. Men hvis du vil gøre mere end at afkrydse et felt, er det værd at dykke ned i, hvad log management faktisk betyder.

Hvad betyder logging?

Enhver form for tidsmæssige begivenhedsdata er en log. Traditionelt tænker vi på logfiler som lange, komplicerede tekstfiler, men nutidens logfiler kan komme fra næsten hvor som helst, i enhver form. En virusscanner, der holder styr på klientopdateringshændelser i sin database – det er også en log. Netværksflowdata fra en virtuel privat sky i AWS? Er igen også en log. Og selvfølgelig er der alle de sædvanlige mistænkte som Windows Event Logs, webserverlogfiler, filadgangslogger osv.

Hvad er log management?

Hvis vi har logfiler, hvorfor behøver de så styring? Udtrykket “log management” blev født ud af en tid, hvor logfiler hovedsageligt var tekstfiler, administratorer kæmpede med diskplads og log99 overgik til log00. I den forbindelse blev det nødvendigt at logs skulle “styres væk”, så kildesystemet kunne trække vejret igen.

Mens tekstfiler gjorde plads til Syslog, API’er og databaser, er det enkle log00 eksempel stadig udgangspunktet for log management. Måske ikke så meget med hensyn til diskplads i disse dage, men for at sikre, at vi fanger logfiler, før de forsvinder. Det er overraskende, hvor mange systemer der stadig overskriver deres logfiler, og hvor hurtigt de gør det. Ofte eksisterer logfiler kun i 24 timer eller mindre, før de overskrives og forsvinder. Hvis man ønsker at få noget ud af disse logdata senere, skal man sørge for, at de indsamles og ikke går tabt.

De forskellige trin i log management

Vi har nu klargjort, hvad en logbesked er, og hvorfor de skal registreres, men hvordan får vi dette til at fungere i praksis?

Logindsamling

Først skal logmeddelelsen indsamles. Den skal enten afhentes (løsningen henter det), ellers skal den sættes lige uden for vores hoveddør (løsningen samler det). Logindsamling kan opnås for ægte logfiler ved at logge ind på et system og hente dem ved hjælp af SCP eller SFTP. Alternativt kan kildesystemet konfigureres til at aflevere logfiler med løsningens indbyggede FTP-server regelmæssigt. Bortset fra filer kan det være Syslog-data (udbredt til netværksenheder) eller SNMP-fælder. I Windows-verdenen kan det være en agent, en Windows Event Forwarding Collector eller WMI. Det kan være ODBC til databaser. Office 365 Management API eller Defender Alert API eller EventHubs API. En S3 bucket.

Metoderne til logindsamling er faktisk uendelige. Men det er vigtigt, at log management løsningen understøtter de platforme og teknikker, du bruger til at generere logdata. Ellers vil der være blinde pletter.

Centraliseret opsamling af logs

En grund til at indsamle logfiler er at sikre, at de bor et sikkert sted, og et sted, hvor du hurtigt kan tilgå dem. Det nytter ikke at have logfiler mange forskellige steder. Centraliseret logaggregation er derfor en hurtig måde at få værdi ud af logfiler. Du skal til enhver tid vide, hvor de er, og hvordan du får adgang til dem.

Den valgte løsning skal implementeres effektivt og uden ekstra omkostninger i distribuerede miljøer. For eksempel kan et fjerntliggende sted producere et overraskende antal logbeskeder, der vil mætte WAN-linket. Tilsvarende kan logudgang og indtrængen for visse skyplatforme føre til uoverkommelige omkostninger. I disse scenarier kan det være meget vigtigt at opbevare logfiler, der er gemt lokalt eller med dem i skyen, men stadig være i stand til at søge gennem dem eksternt fra et centralt søgehoved. Igen skal løsningen være fleksibel nok til at tilpasse sig dine behov og miljø.

Langvarig loglagring, logretention og logrotation

En beslutning, som enhver kunde skal tage, er, hvor længe de skal gemme logbeskeder. Der er en række overvejelser her:

  • Compliance: er der nogen lovgivningsmæssige årsager til, at logbeskeder skal opbevares eller kasseres? PCI, GDPR og virksomhedspolitikker spiller ind her. Både til data, der skal opbevares, såvel som data, der skal kasseres. Det er fordelagtigt at indføre politikker for fastholdelse af granulater. Måske skal specifikke logmeddelelser, der indeholder visse personligt identificerbare oplysninger, opbevares i en kortere periode, eller nogle af deres felter skal krypteres.
  • Driftsbehov: er der visse anvendelsestilfælde, hvor det at have en logbesked ville være gavnligt efter det faktum? For eksempel, hvor længe efter at aktiviteten fandt sted kunne der realistisk (eller lovligt) være et tredjepartsophavsretskrav mod en studerende, der downloadede film ulovligt på universitetets netværk?
  • Logvolumen og pris: logmeddelelser optager diskplads, og diskplads koster penge. Nogle leverandører opkræver endda for mængden af ​​data, der er gemt ved hjælp af deres værktøjer. Det fører til en bestemt pris for hver dag, hvor logbeskeder gemmes og opbevares. I sidste ende kommer det punkt, hvor omkostningerne ved at opbevare logfiler opvejer længere end de fordele, de kan levere. Så skal de sandsynligvis kasseres.

Valg af den rigtige lagerløsning

Når det gælder selve lagringen af ​​logfiler, er der forskellige måder at adressere det på. Nogle sky- og administrerede tjenester inkluderer alle lageromkostninger i en abonnementspris. Alligevel har ekstra tilbageholdelse tendens til at være dyrt. Og der er ringe kontrol over, hvad der gemmes hvor og hvor længe, ​​med dataene, der forlader kundens ejerskab.

Med andre løsninger ejes data af de kunder, der implementerer deres egne lagringsniveauer. Afhængigt af arkitekturen kan svaret muligvis automatisk flytte ældre data til et langsommere lagringsniveau (Eks. langsommere disk NAS snarere end DAS/SAN og SSD’er). Nogle leverandører sender logdata til et offline- eller “arkiv” -niveau. Hvilket kræver en langsom gendannelsesproces, hvis logdataene faktisk er nødvendige.

Som sædvanlig giver en fleksibel løsning mest kontrol over logopbevaring og omkostninger. Vedligeholdelse af ejerskab af data, lagring af forskellige logmeddelelser i forskellige mængder, beskyttelse af følsomme data, mens du stadig er i stand til at søge i dem, samt at løsningen administrerer lagringsniveauer automatisk, bør fjerne de fleste udfordringer ved en ufleksibel log management løsning.

Loganalyse, logsøgning og rapportering – Hvorfor bruge log management?

Så hvor efterlader det os? Vi har samlet logfiler, og vi har sikret, at de opbevares centralt og i den rigtige tid. Men efter alt dette arbejde giver det helt sikkert mening at bruge dem til noget!

Det er her log management bliver til SIEM eller security information and event management. Sikkerhed er et vigtigt fokusområde, med SIEM kan enhver begivenhed fra en logfil findes, advares og visualiseres gennem dashboards og rapporter.

Så indsamling og lagring af logfiler er et vigtigt første skridt. Nogle gange er indsamling og lagring af logfiler alt, hvad der er nødvendigt for at imødekomme nogle krav for compliance. Den virkelige værdi begynder dog at komme ud af alle de ting, du kan gøre med logfiler. For eksempel

Med et SIEM får du adgang til den fulde kraft af logfiler. Alle logmeddelelser er centralt tilgængelige næsten øjeblikkeligt. Dette betyder, at du altid vil vide, hvor du skal foretage fejlfinding. Uanset om det er netværksforbindelsesproblemer, virusscannervarsler, brugere, der bliver ved med at låse sig ude og alle andre ting, der ellers ville have krævet en manuel jagt gennem logfiler, der er svære at læse, fra en lang række systemer – hvis de stadig er tilgængelige.

For endnu mere avancerede funktionaliteter, der overgår log management værktøjer, kan du tjekke nogle af de andre blogs på LogPoint sitet!

Kontakt LogPoint

Kontakt os og lær hvorfor markedsledende firmaer vælger LogPoint:

Kontakt LogPoint

Få mere at vide om LogPoint

Book en demo
Kundehistorier
Kundeanmeldelser