Datasäkerhet för Azure Monitor-loggar

Den här artikeln beskriver hur Azure Monitor samlar in, bearbetar och skyddar loggdata och beskriver säkerhetsfunktioner som du kan använda för att skydda Din Azure Monitor-miljö ytterligare. Informationen i den här artikeln är specifik för Azure Monitor-loggar och kompletterar informationen i Azure Trust Center.

Azure Monitor-loggar hanterar dina molnbaserade data på ett säkert sätt med hjälp av:

  • Dataavgränsning
  • Datakvarhållning
  • Fysisk säkerhet
  • Incidenthantering
  • Efterlevnad
  • Certifieringar av säkerhetsstandarder

Kontakta oss med frågor, förslag eller problem med någon av följande information, inklusive våra säkerhetsprinciper på Azure Support alternativ.

Skicka data på ett säkert sätt med TLS 1.2

För att säkerställa säkerheten för data under överföring till Azure Monitor rekommenderar vi starkt att du konfigurerar agenten så att den använder minst TLS (Transport Layer Security) 1.2. Äldre versioner av TLS/Secure Sockets Layer (SSL) har visat sig vara sårbara och även om de fortfarande arbetar för att tillåta bakåtkompatibilitet rekommenderas de inte, och branschen övergår snabbt till att överge stödet för dessa äldre protokoll.

PCI Security Standards Council har satt en tidsfrist till den 30 juni 2018 för att inaktivera äldre versioner av TLS/SSL och uppgradera till säkrare protokoll. Om dina agenter inte kan kommunicera över minst TLS 1.2 när Azure har upphört med det äldre stödet kan du inte skicka data till Azure Monitor-loggar.

Vi rekommenderar att du inte uttryckligen anger att din agent endast ska använda TLS 1.2 om det inte är absolut nödvändigt. Att tillåta agenten att automatiskt identifiera, förhandla och dra nytta av framtida säkerhetsstandarder är att föredra. Annars kan du missa den extra säkerheten för de nyare standarderna och eventuellt uppleva problem om TLS 1.2 någonsin blir inaktuell till förmån för dessa nyare standarder.

Plattformsspecifik vägledning

Plattform/språk Support Mer information
Linux Linux-distributioner brukar förlita sig på stöd för OpenSSL för TLS 1.2. Kontrollera OpenSSL-ändringsloggen för att bekräfta att din version av OpenSSL stöds.
Windows 8.0 – 10 Stöds och aktiveras som standard. Bekräfta att du fortfarande använder standardinställningarna.
Windows Server 2012 - 2016 Stöds och aktiveras som standard. Bekräfta att du fortfarande använder standardinställningarna
Windows 7 SP1 och Windows Server 2008 R2 SP1 Stöds men är inte aktiverat som standard. Mer information om hur du aktiverar finns på sidan för TLS-registerinställningar (Transport Layer Security ).

Dataavgränsning

När dina data har matats in av Azure Monitor hålls data logiskt åtskilda för varje komponent i tjänsten. Alla data taggas per arbetsyta. Den här taggningen bevaras under hela datalivscykeln och framtvingas på varje lager i tjänsten. Dina data lagras i en dedikerad databas i lagringsklustret i den region som du har valt.

Datakvarhållning

Indexerade loggsökningsdata lagras och behålls enligt din prisplan. Mer information finns i Prissättning för Log Analytics.

Som en del av ditt prenumerationsavtal behåller Microsoft dina data enligt villkoren i avtalet. När kunddata tas bort förstörs inga fysiska enheter.

I följande tabell visas några av de tillgängliga lösningarna och innehåller exempel på vilken typ av data de samlar in.

Lösning Datatyper
Kapacitet och prestanda Prestandadata och metadata
Uppdateringshantering Metadata och tillståndsdata
Logghantering Användardefinierade händelseloggar, Windows-händelseloggar och/eller IIS-loggar
Spårning av ändringar Programvaruinventering, Metadata för Windows-tjänsten och Linux-daemon och Windows-/Linux-filmetadata
SQL- och Active Directory-utvärdering WMI-data, registerdata, prestandadata och SQL Server dynamiska hanteringsvyresultat

I följande tabell visas exempel på datatyper:

Datatyp Fält
Varning Aviseringsnamn, Aviseringsbeskrivning, BaseManagedEntityId, Problem-ID, IsMonitorAlert, RuleId, ResolutionState, Prioritet, Allvarlighetsgrad, Kategori, Ägare, ResolvedBy, TimeRaised, TimeAdded, LastModified, LastModifiedBy, LastModifiedExceptRepeatCount, TimeResolved, TimeResolutionStateLastModified, TimeResolutionStateLastModifiedInDB, RepeatCountCount
Konfiguration CustomerID, AgentID, EntityID, ManagedTypeID, ManagedTypePropertyID, CurrentValue, ChangeDate
Händelse EventId, EventOriginalID, BaseManagedEntityInternalId, RuleId, PublisherId, PublisherName, FullNumber, Number, Category, ChannelLevel, LoggingComputer, EventData, EventParameters, TimeGenerated, TimeAdded
Observera: När du skriver händelser med anpassade fält i Windows-händelseloggen samlar Log Analytics in dem.
Metadata BaseManagedEntityId, ObjectStatus, OrganizationalUnit, ActiveDirectoryObjectSid, PhysicalProcessors, NetworkName, IPAddress, ForestDNSName, NetbiosComputerName, VirtualMachineName, LastInventoryDate, HostServerNameIsVirtualMachine, IP Address, NetbiosDomainName, LogicalProcessors, DNSName, DisplayName, DomainDnsName, ActiveDirectorySite, PrincipalName, OffsetInMinuteFromGreenwichTime
Prestanda ObjectName, CounterName, PerfmonInstanceName, PerformanceDataId, PerformanceSourceInternalID, SampleValue, TimeSampled, TimeAdded
Tillstånd StateChangeEventId, StateId, NewHealthState, OldHealthState, Context, TimeGenerated, TimeAdded, StateId2, BaseManagedEntityId, MonitorId, HealthState, LastModified, LastGreenAlertGenerated, DatabaseTimeModified

Fysisk säkerhet

Azure Monitor hanteras av Microsofts personal och alla aktiviteter loggas och kan granskas. Azure Monitor drivs som en Azure-tjänst och uppfyller alla efterlevnads- och säkerhetskrav för Azure. Du kan visa information om den fysiska säkerheten för Azure-tillgångar på sidan 18 i Säkerhetsöversikt för Microsoft Azure. Fysiska åtkomsträttigheter till säkra områden ändras inom en arbetsdag för alla som inte längre har ansvar för Azure Monitor-tjänsten, inklusive överföring och avslutning. Du kan läsa om den globala fysiska infrastruktur som vi använder på Microsoft Datacenter.

Incidenthantering

Azure Monitor har en process för incidenthantering som alla Microsoft-tjänster följer. För att sammanfatta:

  • Använd en modell med delat ansvar där en del av säkerhetsansvaret tillhör Microsoft och en del tillhör kunden
  • Hantera Azure-säkerhetsincidenter:
    • Starta en undersökning vid identifiering av en incident
    • Utvärdera påverkan och allvarlighetsgrad för en incident av en teammedlem för jourincidenter. Baserat på bevis kan utvärderingen leda till ytterligare eskalering till säkerhetshanteringsteamet.
    • Diagnostisera en incident av experter på säkerhetsåtgärder för att genomföra den tekniska eller kriminaltekniska undersökningen, identifiera strategier för inneslutning, åtgärder och lösningar. Om säkerhetsteamet tror att kunddata kan ha exponerats för en olaglig eller obehörig person börjar parallell körning av processen för kundincidentmeddelande parallellt.
    • Stabilisera och återhämta sig från incidenten. Incidenthanteringsteamet skapar en återställningsplan för att åtgärda problemet. Krishanteringssteg som quarantining påverkade system kan inträffa omedelbart och parallellt med diagnos. Långsiktiga åtgärder kan planeras som inträffar efter att den omedelbara risken har passerat.
    • Stäng incidenten och utför en obduktion. Incidenthanteringsteamet skapar en obduktion som beskriver information om incidenten, med avsikt att ändra principer, procedurer och processer för att förhindra att händelsen upprepas.
  • Meddela kunder om säkerhetsincidenter:
    • Fastställ omfattningen av berörda kunder och ge alla som påverkas ett så detaljerat meddelande som möjligt
    • Skapa ett meddelande för att ge kunderna tillräckligt detaljerad information så att de kan utföra en undersökning på sin sida och uppfylla alla åtaganden de har gjort till sina slutanvändare utan att i onödan fördröja meddelandeprocessen.
    • Bekräfta och deklarera incidenten efter behov.
    • Meddela kunder med ett incidentmeddelande utan orimlig fördröjning och i enlighet med juridiska eller avtalsmässiga åtaganden. Meddelanden om säkerhetsincidenter skickas till en eller flera av en kunds administratörer på något sätt som Microsoft väljer, inklusive via e-post.
  • Genomför teamets beredskap och utbildning:
    • Microsofts personal krävs för att slutföra säkerhets- och medvetenhetsutbildningen, vilket hjälper dem att identifiera och rapportera misstänkta säkerhetsproblem.
    • Operatörer som arbetar med Microsoft Azure-tjänsten har ytterligare utbildningsskyldigheter kring sin åtkomst till känsliga system som är värdar för kunddata.
    • Microsofts säkerhetspersonal får specialiserad utbildning för sina roller

Även om det är mycket sällsynt meddelar Microsoft varje kund inom en dag om betydande förlust av kunddata inträffar.

Mer information om hur Microsoft svarar på säkerhetsincidenter finns i Microsoft Azure Security Response i molnet.

Efterlevnad

Azure Monitors programutvecklings- och tjänstteams program för informationssäkerhet och styrning stöder företagets affärskrav och följer lagar och förordningar enligt beskrivningen i Microsoft Azure Trust Center och Microsoft Trust Center Compliance. Hur Azure Monitor-loggar upprättar säkerhetskrav, identifierar säkerhetskontroller, hanterar och övervakar risker beskrivs också där. Varje år granskar vi principer, standarder, procedurer och riktlinjer.

Varje medlem i utvecklingsteamet får formell programsäkerhetsutbildning. Internt använder vi ett versionskontrollsystem för programvaruutveckling. Varje programvaruprojekt skyddas av versionskontrollsystemet.

Microsoft har ett säkerhets- och efterlevnadsteam som övervakar och utvärderar alla tjänster på Microsoft. Informationssäkerhetsansvariga utgör teamet och de är inte associerade med teknikteamen som utvecklar Log Analytics. Säkerhetstjänstemännen har en egen hanteringskedja och utför oberoende utvärderingar av produkter och tjänster för att säkerställa säkerhet och efterlevnad.

Microsofts styrelse meddelas av en årlig rapport om alla informationssäkerhetsprogram på Microsoft.

Log Analytics programvaruutvecklings- och tjänstteam arbetar aktivt med Microsofts juridiska team och efterlevnadsteam och andra branschpartner för att skaffa olika certifieringar.

Certifieringar och intyg

Azure Log Analytics uppfyller följande krav:

Anteckning

I vissa certifieringar/attesteringar visas Azure Monitor-loggar under det tidigare namnet Operational Insights.

Dataflöde för molnbaserad databehandling

Följande diagram visar en molnsäkerhetsarkitektur som informationsflödet från ditt företag och hur det skyddas i takt med att det flyttas till Azure Monitor, vilket slutligen visas av dig i Azure Portal. Mer information om varje steg följer diagrammet.

Bild av datainsamling och säkerhet för Azure Monitor-loggar

1. Registrera dig för Azure Monitor och samla in data

För att din organisation ska kunna skicka data till Azure Monitor-loggar konfigurerar du en Windows- eller Linux-agent som körs på virtuella Azure-datorer eller på virtuella eller fysiska datorer i din miljö eller någon annan molnleverantör. Om du använder Operations Manager från hanteringsgruppen konfigurerar du Operations Manager-agenten. Användare (som kan vara du, andra enskilda användare eller en grupp personer) skapar en eller flera Log Analytics-arbetsytor och registrerar agenter med något av följande konton:

En Log Analytics-arbetsyta är den plats där data samlas in, aggregeras, analyseras och presenteras. En arbetsyta används främst som ett sätt att partitioneras data och varje arbetsyta är unik. Du kanske till exempel vill att dina produktionsdata ska hanteras med en arbetsyta och dina testdata hanteras med en annan arbetsyta. Arbetsytor hjälper också en administratör att kontrollera användaråtkomsten till data. Varje arbetsyta kan ha flera associerade användarkonton och varje användarkonto kan komma åt flera Log Analytics-arbetsytor. Du skapar arbetsytor baserat på datacenterregion.

För Operations Manager upprättar Operations Manager-hanteringsgruppen en anslutning till Azure Monitor-tjänsten. Sedan konfigurerar du vilka agenthanterade system i hanteringsgruppen som ska kunna samla in och skicka data till tjänsten. Beroende på vilken lösning du har aktiverat skickas data från dessa lösningar antingen direkt från en Operations Manager-hanteringsserver till Azure Monitor-tjänsten, eller på grund av mängden data som samlas in av det agenthanterade systemet, direkt från agenten till tjänsten. För system som inte övervakas av Operations Manager ansluter var och en på ett säkert sätt till Azure Monitorservice direkt.

All kommunikation mellan anslutna system och Azure Monitor-tjänsten krypteras. TLS-protokollet (HTTPS) används för kryptering. Microsoft SDL-processen följs för att säkerställa att Log Analytics är uppdaterat med de senaste framstegen inom kryptografiska protokoll.

Varje typ av agent samlar in loggdata för Azure Monitor. Vilken typ av data som samlas in beror på konfigurationen av din arbetsyta och andra funktioner i Azure Monitor.

2. Skicka data från agenter

Du registrerar alla agenttyper med en registreringsnyckel och en säker anslutning upprättas mellan agenten och Azure Monitor-tjänsten med certifikatbaserad autentisering och TLS med port 443. Azure Monitor använder ett hemligt arkiv för att generera och underhålla nycklar. Privata nycklar roteras var 90:e dag och lagras i Azure och hanteras av Azure-åtgärderna som följer strikta regler och efterlevnadsmetoder.

Med Operations Manager upprättar hanteringsgruppen som är registrerad på en Log Analytics-arbetsyta en säker HTTPS-anslutning med en Operations Manager-hanteringsserver.

För Windows- eller Linux-agenter som körs på virtuella Azure-datorer används en skrivskyddad lagringsnyckel för att läsa diagnostikhändelser i Azure-tabeller.

Om en agent rapporterar till en Operations Manager-hanteringsgrupp som är integrerad med Azure Monitor, lagras insamlade data lokalt i en tillfällig cache på hanteringsservern om hanteringsservern inte kan kommunicera med tjänsten. De försöker skicka om data var åttonde minut i två timmar. För data som kringgår hanteringsservern och skickas direkt till Azure Monitor är beteendet konsekvent med Windows-agenten.

Windows- eller hanteringsserveragentens cachelagrade data skyddas av operativsystemets autentiseringsarkiv. Om tjänsten inte kan bearbeta data efter två timmar köar agenterna data. Om kön blir full börjar agenten släppa datatyper, med början med prestandadata. Gränsen för agentkö är en registernyckel så att du kan ändra den om det behövs. Insamlade data komprimeras och skickas till tjänsten, vilket kringgår Operations Manager-hanteringsgruppens databaser, så att de inte läggs till någon belastning. När insamlade data har skickats tas de bort från cachen.

Enligt beskrivningen ovan skickas data från hanteringsservern eller direktanslutna agenter via TLS till Microsoft Azure-datacenter. Du kan också använda ExpressRoute för att ge extra säkerhet för data. ExpressRoute är ett sätt att ansluta direkt till Azure från ditt befintliga WAN-nätverk, till exempel ett MPLS-VPN (multi-protocol label switching), som tillhandahålls av en nätverkstjänstleverantör. Mer information finns i ExpressRoute.

3. Azure Monitor-tjänsten tar emot och bearbetar data

Azure Monitor-tjänsten ser till att inkommande data kommer från en betrodd källa genom att verifiera certifikat och dataintegriteten med Azure-autentisering. De obearbetade rådata lagras sedan i en Azure Event Hub i regionen som data så småningom lagras i vila. Vilken typ av data som lagras beror på vilka typer av lösningar som har importerats och använts för att samla in data. Sedan bearbetar Azure Monitor-tjänsten rådata och matar in dem i databasen.

Kvarhållningsperioden för insamlade data som lagras i databasen beror på den valda prisplanen. För den kostnadsfria nivån är insamlade data tillgängliga i sju dagar. För den betalda nivån är insamlade data tillgängliga i 31 dagar som standard, men kan utökas till 730 dagar. Data lagras krypterade i vila i Azure Storage för att säkerställa datasekretess och data replikeras i den lokala regionen med hjälp av lokalt redundant lagring (LRS). De senaste två veckornas data lagras också i SSD-baserad cache och den här cachen krypteras.

Det går inte att ändra data i databaslagringen när de har matats in, men de kan tas bort via sökvägen för rensnings-API:et. Även om data inte kan ändras kräver vissa certifieringar att data hålls oföränderliga och inte kan ändras eller tas bort i lagringen. Data oföränderlighet kan uppnås med hjälp av dataexport till ett lagringskonto som är konfigurerat som oföränderlig lagring.

4. Använd Azure Monitor för att komma åt data

För att komma åt din Log Analytics-arbetsyta loggar du in på Azure Portal med det organisationskonto eller Microsoft-konto som du skapade tidigare. All trafik mellan portalen och Azure Monitor-tjänsten skickas via en säker HTTPS-kanal. När du använder portalen genereras ett sessions-ID på användarklienten (webbläsare) och data lagras i ett lokalt cacheminne tills sessionen avslutas. När cachen avslutas tas den bort. Cookies på klientsidan, som inte innehåller personligt identifierbar information, tas inte bort automatiskt. Sessionscookies markeras HTTPOnly och skyddas. Efter en förutbestämd inaktivitetsperiod avslutas den Azure Portal sessionen.

Ytterligare säkerhetsfunktioner

Du kan använda dessa ytterligare säkerhetsfunktioner för att skydda Din Azure Monitor-miljö ytterligare. Dessa funktioner kräver mer administratörshantering.

  • Kundhanterade nycklar (säkerhet) – Du kan använda kundhanterade nycklar för att kryptera data som skickas till dina Log Analytics-arbetsytor. Det kräver användning av Azure Key Vault.
  • Privat/kundhanterad lagring – Hantera ditt personligt krypterade lagringskonto och be Azure Monitor att använda det för att lagra övervakningsdata
  • Private Link nätverk – Azure Private Link gör att du på ett säkert sätt kan länka Azure PaaS-tjänster (inklusive Azure Monitor) till ditt virtuella nätverk med hjälp av privata slutpunkter.
  • Azure-kundlåsbox – Customer Lockbox för Microsoft Azure tillhandahåller ett gränssnitt där kunderna kan granska och godkänna eller avvisa begäranden om åtkomst till kunddata. Den används i fall där en Microsoft-tekniker behöver åtkomst till kundinformation under en supportförfrågan.

Manipulering och oföränderlighet

Azure Monitor är en tilläggsbaserad dataplattform, men innehåller bestämmelser för att ta bort data i efterlevnadssyfte. Du kan ange ett lås på Log Analytics-arbetsytan för att blockera alla aktiviteter som kan ta bort data: rensa, ta bort tabeller och datakvarhållningsändringar på tabell- eller arbetsytenivå. Det här låset kan dock fortfarande tas bort.

För att fullständigt manipulera övervakningslösningen rekommenderar vi att du exporterar dina data till en oföränderlig lagringslösning.

Nästa steg