Hva er Azure Monitor og Log Analyctics?

Flere og flere organisasjoner bruker nå Log Analytics-tjenester i Azure på grunn av bruk sammen med Azure Sentinel, Desktop Analytics eller bare for diagnostikk for PaaS-tjenester som kjører i Azure. 
Mange organisasjoner har satt opp flere Log Analytics-arbeidsområder, så kommer spørsmålet om man skal ha ett eller flere Log Analytics-arbeidsområder? hvordan fungerer tjenesten? hvorfor tar det så lang tid før data vises innenfor? Hva er forskjellen mellom de forskjellige agentene? La oss ta en dypdykk gjennom Log Analytics og andre moduler som er koblet til den, som Sentinel og Azure Monitor.

Felleskomponenter

Bildet nedenfor er ment som et perspektiv på høyt nivå av de forskjellige komponentene i Log Analytics rundt tjenester som Sentinel og Azure Monitor.

For å se i full størrelse: https://i.ibb.co/mNMdkN8/image.pngInnenfor Log Analytics har vi noe som kalles et Log Analytics-arbeidsområde som i hovedsak er en database som inneholder data. Log Analytics-arbeidsområdet opprettes innenfor en bestemt region og har en spesifikk oppbevaringstid som definerer hvor lenge data skal lagres i logganalysearbeidsområdet (databasen). Som standard er dette 30 dager, men kan konfigureres til å være så lenge som 730 dager.

Alle data som er lagret i et arbeidsområde er skrivebeskyttet og kan ikke endres. Alle handlingene den tillater oss å samle inn nye data eller data som også kan renses med Purge API. Se: https://docs.microsoft.com/en-us/rest/api/loganalytics/workspacepurge/purge

Dette er vanligvis for GDPR-formål hvor du må fjerne visse deler av dataene.

Arbeidsområdet består av forskjellige tabeller med lagring av forskjellige typer data avhengig av datakilden. Som standard har alle tabellene samme type oppbevaring som arbeidsområdet, men kan også tilpasses slik at du kan ha forskjellige typer oppbevaring av de forskjellige tabellene.

Du kan også bruke denne spørringen til å se på de forskjellige logganalysetabellene som samler inn data.

search "*" | summarize count() by $table | sort by count_ desc

Logganalyse har forskjellige former for data som kan tas inn i databasen. Noen er basert på agenter installert på maskiner som pusher data eller som bruker API-integrasjoner fra Azure PaaS-tjenester eller tilpasset API som skyver data inn til Data Collector. Du har også konseptet Solutions som er utvidelser til Log Analytics som kan gi utvidet funksjonalitet til dataene som samles inn til et Workspace. En av disse løsningene kan være Azure Sentinel eller Network Performance Monitor som bruker Log Analytics til å lagre data. Det finnes også andre løsninger som integreres med Log Analytics som f.eks

• ITSM-kobling
• Service Map

Du kan se en liste over alle løsningene her: https://docs.microsoft.com/en-us/azure/azure-monitor/monitor-reference

MERK: Noen løsninger har også et egendefinert tidsintervall når de samler inn data, for eksempel Windows Update Analytics som samles inn hver 24. time. Noen løsninger krever også noe tilpasset konfigurasjon og kan også kreve flere agenter installert på endepunktet for å kunne samle inn de nødvendige dataene eller utføre de nødvendige handlingene.

Når data lastes opp til Log Analytics, er det forskjellige mekanismer på plass som bestemmer hvor raskt data blir tilgjengelig eller synlig.

Enkelte løsninger har også ulike opplastingsintervaller. For eksempel når data samles inn vil de bli plassert i kø og lagret på en midlertidig lagringsløsning først slik at Microsoft kan sikre at alle data blir skrevet når tjenesten har nok kapasitet til å behandle dataene, dette er på grunn av overspenningsbeskyttelsen som er på plass. Hvis Log Analytics behandler en ny datakilde, må tjenesten først opprette en ny måltabell i databasen. Når dataene er skrevet til databasen, tar det også litt tid før dataene er indeksert riktig og synlige i spørringene.Du kan også bruke denne eksempelspørringen til å finne ut hvor lang ventetid som påvirker dataene som kommer inn.

AzureDiagnostics | where TimeGenerated > ago(8h) 
| extend E2EIngestionLatency = ingestion_time() - TimeGenerated
| extend AgentLatency = _TimeReceived - TimeGenerated 
| summarize percentiles(E2EIngestionLatency,50,95), percentiles(AgentLatency,50,95) 
by ResourceProvider

Noen data kan også konfigureres til å bli eksportert til en annen datakilde. For noen organisasjoner der du kanskje bruker Splunk eller et annet SIEM-verktøy, eksporteres data fra Log Analytics til det tredjepartsverktøyet. Du har også en mulighet til å konfigurere dataeksport som er en nylig introdusert funksjon.

Agent- og agentarkitektur

Log Analytics kan også samle inn data fra virtuelle maskiner/fysiske maskiner som har en agent installert. Denne agenten er også kjent som MMA-agenten. Når du installerer agenten, må du ha en Workspace ID og en nøkkel som brukes til å autentisere agenten til arbeidsområdet. Når den er koblet til, vil agenten laste ned alle konfigurasjoner som er koblet til arbeidsområdet. Dette fungerer litt annerledes for virtuelle Azure-maskiner siden vi her bruker en Azure Monitor-agent som oppfører seg litt annerledes. Azure Monitor agenten kan også benyttes på virtuelle/fysiske maskiner.

Log Analytics-agenten er basert på System Center Operations Manager-arcthictecture og laster ned den sentraliserte konfigurasjonen ved hjelp av Management Packs (som inneholder løsningene, datakildene og lignende) og data lastes opp komprimert basert på datakildene som er konfigurert i Solutions and data kilder som er definert i arbeidsområdet.

Agenter kan enten kommunisere direkte eller bruke en proxy kjent som en Log Analytics Gateway som vil proxy all trafikk fra agenter internt.

For ikke-støttede operativsystemer der du for eksempel har syslog, kan du også konfigurere en linux-basert VM med log analytics-agenten for å videresende data ved hjelp av rsyslog. https://docs.microsoft.com/en-us/azure/azure-monitor/platform/data-sources-syslog

Som standard når du konfigurerer en løsning for et arbeidsområde, vil alle agenter som er koblet til arbeidsområdet motta løsningen (for Log Analytics-baserte agenter)Dette er kanskje ikke noe du vil ha på for eksempel test-/dev-baserte maskiner, selv om du vil ha logganalyseagenten installert. Du har også muligheten til å bruke noe som heter Solution Scope Configuration som lar deg konfigurere et omfang som løsningen skal gjelde for. Bakgrunnen for dette er at noen løsninger vil generere mye data og med dette kan du konfigurere en maskingruppe som løsningen skal omfattes.

Azure Monitor vs Log Analytics agent

Nå som Log Analytics har utviklet seg, har agentene også utviklet seg. Den tidligere Log Analytics-agenten som Microsoft for øyeblikket har tilgjengelig (som også er basert på SCOM-arkitekturen) vil bli erstattet med en ny agent kalt Azure Monitor som er standard for alle virtuelle maskiner i Azure som rapporterer til Log Analytics.

Slik det er nå, er Azure Monitor-agenten for øyeblikket i forhåndsvisning og vil erstatte Log Analytics-agenten for både Windows- og Linux-maskiner etter hvert. En forskjell er også hvordan du administrerer Azure Monitor Agents. Siden med den kan du også konfigurere regler for datainnsamling der du definerer hva slags data hver type agent samler inn i stedet for å definere det på et arbeidsområdenivå. Azure Monitor-agenter har ikke støtte for Window Server 2008.

Det er imidlertid noen forskjeller når det gjelder funksjonalitet for hver av agentene for øyeblikket, som du kan lese mer om her:https://docs.microsoft.com/en-us/azure/azure-monitor/platform/agents-overview#summary-of-agents for det andre bruker Azure Monitor-agenten en System Managed Identity i stedet for workspace nøkkel for å autentisere til Azure Monitor og laste opp data (hendelseslogger og metrics)

Azure Monitor-agenten vil også være innebygd med Azure Arc.Azure Migrate bruker også agenten til å samle inn informasjon om ressurser on-prem som deretter lastes opp til Azure Monitor.

Ressurs vs arbeidsområdebasert tilgang vs tabellnivåbasert tilgang

Som standard har Azure Log Analytics en tilgangstype kalt (standard etter mars 2019)  Use resource eller Worskpace permissions. Dette betyr at brukere som har tilgang til en bestemt ressurs i Azure, for eksempel Web Apps som laster opp diagnostikkdata til Azure Log Analytics, kan se logger for tjenesten selv om de ikke har tilgang til arbeidsområdeobjektet. Dette lar det sentrale IT-teamet ha full tilgang til alle logger og data, og fortsatt gi applikasjonsteamene tilgang til ressursloggene deres uten tilgang til andre datakilder.

Et annet alternativ er å definere tabellnivåbasert tilgang. Dette betyr at du kun gir tilgang til enkelte tabeller innenfor arbeidsområdet. Dette gjøres ved å bruke egendefinerte roller der du definerer tabellene som en del av ressurstypen som sådan

"Actions": [ 
"Microsoft.OperationalInsights/workspaces/read",
"Microsoft.OperationalInsights/workspaces/query/read",
"Microsoft.OperationalInsights/workspaces/query/Heartbeat/read",
"Microsoft.OperationalInsights/workspaces/query/AzureActivity/read" 
],

Dette kan være nyttig for å gi enkelte ressurser tilgang bare til visse data som samles inn i Log Analytics.

Log Analytics and Solutions

Når du bruker Log Analytics sammen med Solutions som beskrevet tidligere som bruker en System Center Operations Manager-arkitektur, når du legger til nye løsninger, oppdaterer du i hovedsak den sentraliserte administrasjonen som deretter lastes ned til agenter som deretter laster opp nye data basert på den nye løsningen.

Det er en haug med løsninger som kan være veldig nyttige sammen med Log Analytics.

• Azure Security Center – Trusseldeteksjon og også samle inn sikkerhetshendelser fra maskiner som en del av konfigurasjonen.
• ITSM Connector – Brukes for integrasjon av Log Analytics med 3.parts ITSM-verktøy. Brukes til å automatisk opprette hendelser eller arbeidselementer når varsler opprettes i Log Analytics. For eksempel System Center Service Manager eller Service Now.
• Azure Sentinel – SIEM og SOAR-løsning som gjør analyser mot data som samles inn i Log Analytics.
• Microsoft Intune – Samler diagnosedata fra Intune til Log Analytics. Dette inkluderer også revisjonslogger og endringer av data fra Intune.
• Network Performance Monitor – NPM tillater overvåking av nettverket mellom to endepunkter ved å bruke ekstra agent på hver side, og tillater også tjeneste monitorering som å undersøke eksterne tjenester fra en agent.
• Office 365 – Samler inn revisjonslogger, kun tilgjengelig som en del av en kobling i Azure Sentinel. Denne løsningen ble fjernet 31. oktober 2020.
• Azure Automation – Denne funksjonen er integrert med Log Analytics og gir både funksjon for endringssporing og oppdateringsadministrasjon. Kan lese mer om endringssporing her – https://docs.microsoft.com/en-us/azure/automation/change-tracking/manage-change-tracking. Når Azure Automation Update Management er aktivert, konfigureres enhver maskin som er koblet til Log Analytics-arbeidsområdet ditt automatisk som en system Hybrid Runbook Worker.

Azure Resources og Diagnostics

Alle ressurser har muligheten til å konfigurere diagnoseinnstillinger, noe som i hovedsak lar logger fra hver ressurs sendes til en sentralisert datakilde. Dette kan enten være

• Log Analytics Workspace
• Event Hub
• Storage Account

Eksemplet nedenfor viser noen av de forskjellige datakildene de forskjellige tjenestene kan sende. Dette gjelder ikke bare Azure PaaS-tjenester, men også andre ressurser som f.eks.

• Azure Resource Manager Activity Log
• Azure Active Directory Audit and Sign-in logs
• Azure Log Analytics Search History

Det er viktig at diagnostikk er aktivert for alle ressurser, slik at du har sentraliserte overvåkings- og loggingsmuligheter. Her er et godt utgangspunkt for å definere en Azure-policy som kan bruke diagnostikkinnstillinger for alle dine nåværende og fremtidige ressurser –>https://github.com/JimGBritt/AzurePolicy/tree/master/AzureMonitor/Scripts

Retention og Azure Storage extension

Som standard bestemmes kostnaden for Azure Log Analytics (inkludert Sentinel) av mengden data som tas inn og også oppbevaringstiden. Log Analytics og Sentinel har imidlertid et tak når det gjelder hvor lenge de kan lagre data. Det er imidlertid med det nye eksportalternativet nå mulig å eksportere sikkerhetslogger og andre data til en lagringskonto ved å bruke den nye innebygde funksjonen.

Dette betyr også at vi kan beholde enkelte hendelse tabeller over lengre tid. Noen tabeller inneholder kanskje bare ytelsesmålinger eller detaljert logging av tjenester som kanskje ikke er verdt å lagre over en lengre periode.

Så hvis vi for eksempel ønsker å lagre alle sikkerhetshendelser i 24 måneder, vil dette koste rundt 121$ for 60 GB per måned, mens eksport av de samme dataene til en lagringskonto i lengre tid med samme størrelse vil koste ca. 20$  (Bare husk at det er noen begrensninger for støttede tabeller som kan eksporteres)

Med data som også er lagret i en lagringskonto, kan du fortsatt få tilgang fra en Log Analytics Kusto-spørring.

Ved å bruke eksterndataoperatøren i Kusto kan du også spørre direkte i lagringskontodata. Denne operatøren kan enten slå opp data som er lagret i en offentlig tilgjengelig lagringskonto eller andre tilgjengelige datakilder. Noen eksempler her på hvordan den kan slå opp ekstern datalagring:https://docs.microsoft.com/en-us/azure/data-explorer/kusto/query/externaldata-operator?pivots=azuredataexplorer

Azure Arc og Azure Monitor?

Med Azure Arc for servere gir det muligheter for både administrasjon, policykontroll og overvåking av virtuelle maskiner. Et eksempel er at Azure Arc tilbyr Azure Policy-funksjonalitet for virtuelle maskiner. Med Azure Arc 1.0 støtter den også Azure Monitor-agent.

https://azure.microsoft.com/en-us/updates/new-azure-monitor-agent-and-data-collection-rules-capabilities-released

Så dette lar deg også installere Azure Monitor-agenten på Azure Arc-aktiverte servere.

New-AzConnectedMachineExtension -Name AMAWindows -ExtensionType AzureMonitorWindowsAgent
 -Publisher Microsoft.Azure.Monitor -ResourceGroupName <resource-group-name>
 -MachineName <virtual-machine-name> -Location <location>

Med Azure Arc opprettet tjenesten også en administrert identitet for serveren, som betyr at den vil kommunisere med Azure AD-identiteten til Log Analytics-arbeidsområdet i stedet for en arbeidsområde-ID og nøkkel.

Azure Log Analytics og Private Link

Som standard, hvis du har Azure Monitor eller har Log Analytics-agenter installert på lokale maskiner, vil den kommunisere med de offentlige FQDN-ene til tjenesten og ikke via noen VPN- eller ExpressRoute-forbindelse organisasjonen din kan ha mot Azure. Det er imidlertid mulig å koble til ved å bruke dine private tilkoblinger via Private Link nå. Det er imidlertid noen forbehold:

• Du må bruke den nyeste versjonen av Log Analytics-agenten for Windows eller Linux.
• Log Analytics Gateway støtter ikke Private Link.

Private Link-konfigurasjon for Log Analytics kan også brukes til å bestemme hvor operatører faktisk kan kjøre spørringer fra.

Hvis du imidlertid ønsker å bruke privat lenke for lokale ressurser, må du være klar over at du må oppdatere DNS-sonene for å peke til tjenestens interne FQDN også. Når du oppretter en privat kobling, vil Azure automatisk opprette en privat sone som inneholder A-record for den private koblingen.

Beste praksis for design og oppsett

Så det siste aspektet er når det kommer til beste fremgangsmåter for distribusjon av Log Analytics-arbeidsområder eller bruk av Log Analytics generelt for enhver distribusjon.

• Bruk så få Workspace som mulig – Tidligere trengte du kanskje å ha flere på grunn av oppbevaring og kostnad for ytelsesmålinger, men nå med ny innebygd funksjonalitet bør du ha en som inneholder alle logger/aktiviteter
• Bruk en for hver region – Fordi for kostnader og tregheter, kan det også være forskjellige krav til etterlevelse per land eller gjeldende lover.
• Bruk Table level retention – Dette for å ha mer kontroll over kostnadene, trenger du ikke ytelsesberegninger for de siste 90 dagene?!
• Bruk Azure-policyer både for å installere overvåkingsagenter og aktivere diagnostikk for alle Azure-relaterte tjenester som er i bruk – Dette er ikke bare for sikkerhetsformål, men også for å varsle om Azure relaterte strømbrudd.
• Sett opp varsling av vanlige hendelser både for sikkerhet, men også for driftsperspektiv – De fleste har logganalyse aktivert og samler inn data, men få bruker tid på å lage varslings- og overvåkingsregler for tjenestene slik at de kan bruke automatisering eller bli varslet hvis noe skjer. Dette kan også automatiseres ved hjelp av Terraform eller Azure Resource Manager, slik at du enkelt kan definere nye varsler når du ønsker å bli varslet om et strømbrudd eller en endring.
• Bruk tid på å se på loggkildene og administrere kostnadene – Mange organisasjoner etter å ha satt opp Log Analytics inntar bare data uten å bruke dataene som kommer inn eller kontrollere hvor mye data som blir lagret. Noen tjenester kan samle inn mange detaljerte data som du kanskje ikke trenger eller vil ha i det hele tatt. Ha noen som kan ha ansvar for å følge opp hva slags data som samles inn og gjøre endringer deretter. Også nå med Azure Monitor-agenter og datainnsamlingsregler kan vi definere mer korrekte regler for hvilke data som skal samles inn og hvor de skal lagres.
• Definer riktig RBAC- og tabellnivåbasert tilgangskontroll – I de fleste tilfeller kan det hende du samler inn mye sensitive data eller tilgangslogger som ikke burde være tilgjengelig for de fleste operatører. Med log Analytics og eller Sentinel kan du nå definere riktig RBAC for de fleste operatører for å sikre at de bare kan få tilgang til visse data. 
• For langsiktig oppbevaring, flytt data til en Azure Storage-konto

Vær oppmerksom på oppdateringene! – Det skjer mange oppdateringer og endringer for Log Analytics og Azure Monitor, som kan sees her –> https://azure.microsoft.com/nb-no/updates/?category=management-tools