Datasäkerhet för Azure Monitor-loggar

  • Artikel

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 i Azures supportalternativ.

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

För att säkerställa säkerheten för data som överförs till Azure Monitor rekommenderar vi starkt att du konfigurerar agenten att använda minst TLS (Transport Layer Security) 1.3. Ä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 fastställt 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.3 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.3 om det inte behövs. 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.3 någonsin är inaktuell till förmån för dessa nyare standarder.

Plattformsspecifik vägledning

Plattform/språk Support Mer information
Linux Linux-distributioner tenderar att 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 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 hela tjänsten. Alla data taggas per arbetsyta. Den här taggningen bevaras under 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 bevaras 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 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, Windows-tjänsten och Linux-daemonmetadata och Windows/Linux-filmetadata
SQL- och Active Directory-utvärdering WMI-data, registerdata, prestandadata och resultat för dynamisk hantering av SQL Server

I följande tabell visas exempel på datatyper:

Datatyp Fält
Varning Aviseringsnamn, Aviseringsbeskrivning, BaseManagedEntityId, Problem-ID, IsMonitorAlert, RuleId, ResolutionState, Priority, Severity, Category, Owner, ResolvedBy, TimeRaised, TimeAdded, LastModifiedBy, LastModifiedExceptRepeatCount, TimeResolved, TimeResolutionStateLastModified, TimeResolutionStateLastModifiedInDB, RepeatCountCount
Konfiguration CustomerID, AgentID, EntityID, ManagedTypeID, ManagedTypePropertyID, CurrentValue, ChangeDate
Event EventId, EventOriginalID, BaseManagedEntityInternalId, RuleId, PublisherId, PublisherName, FullNumber, Number, Category, ChannelLevel, LoggingComputer, EventData, EventParameters, TimeGenerated, TimeAdded
Obs! 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 Krav på Azure-efterlevnad och säkerhet. Du kan visa information om den fysiska säkerheten för Azure-tillgångar på sidan 18 i Microsoft Azure-säkerhetsöversikten. 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 uppsägning. 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ölja. Sammanfattnings skull:

  • Använd en modell för 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 allvarlighetsgraden för en incident av en jourmedlem i teamet för incidenthantering. Baserat på bevis kan utvärderingen eller kanske inte leda till ytterligare eskalering till säkerhetshanteringsteamet.
    • Diagnostisera en incident av säkerhetsexperter för att utföra den tekniska eller kriminaltekniska undersökningen, identifiera inneslutning, åtgärder och arbeta med strategier. Om säkerhetsteamet anser 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. Kris inneslutningssteg 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 postmortering som beskriver detaljerna i incidenten, med avsikt att se över principer, procedurer och processer för att förhindra att händelsen upprepas.
  • Meddela kunder om säkerhetsincidenter:
    • Fastställa omfattningen av berörda kunder och för att 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 i slutet och uppfylla alla åtaganden som de har gjort mot 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 något rättsligt eller avtalsmässigt åtagande. Meddelanden om säkerhetsincidenter levereras till en eller flera av en kunds administratörer på något sätt som Microsoft väljer, inklusive via e-post.
  • Genomför teamberedskap och utbildning:
    • Microsofts personal måste 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 tilläggsutbildningsskyldigheter kring deras å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 ovanligt 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

Programvaruutvecklings- och tjänstteamets program för informationssäkerhet och styrning i Azure Monitor stöder företagets affärskrav och följer lagar och föreskrifter 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, förfaranden 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 de teknikteam som utvecklar Log Analytics. Säkerhetstjänstemännen har en egen hanteringskedja och genomför oberoende utvärderingar av produkter och tjänster för att säkerställa säkerhet och efterlevnad.

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

Log Analytics-teamet för programvaruutveckling och -tjänst arbetar aktivt med Microsofts juridiska team och efterlevnadsteam och andra branschpartner för att förvärva olika certifieringar.

Certifieringar och intyg

Azure Log Analytics uppfyller följande krav:

Kommentar

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

Dataflöde för molnbaserad databehandlingssäkerhet

I följande diagram visas en molnsäkerhetsarkitektur som informationsflödet från ditt företag och hur det skyddas, precis som när det flyttas till Azure Monitor, vilket slutligen visas av dig i Azure-portalen. 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 konfigurerar du Operations Manager-agenten från hanteringsgruppen. 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 hjälp av 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 De Azure-åtgärder som följer strikta regler och efterlevnadsmetoder.

Med Operations Manager upprättar hanteringsgruppen som registrerats med 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.

Med all agentrapportering till en Operations Manager-hanteringsgrupp som är integrerad med Azure Monitor, lagras de insamlade data lokalt i en tillfällig cache på hanteringsservern om hanteringsservern inte kan kommunicera med tjänsten. De försöker skicka data igen 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 och börjar med prestandadata. Agentkögränsen är en registernyckel så att du kan ändra den om det behövs. Insamlade data komprimeras och skickas till tjänsten och 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 cacheminnet.

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 och Använder min agenttrafik min Azure ExpressRoute-anslutning?.

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 Hubs i regionen som data så småningom lagras i vila. Vilken typ av data som lagras beror på vilka typer av lösningar som importerades och användes 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 nivån Betald är insamlade data tillgängliga i 31 dagar som standard, men kan utökas till 730 dagar. Data lagras 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) eller zonredundant lagring (ZRS) i regioner som stöds. De senaste två veckornas data lagras också i SSD-baserad cache och den här cachen krypteras.

Data i databaslagringen kan inte ändras 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 har konfigurerats som oföränderlig lagring.

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

För att få åtkomst till din Log Analytics-arbetsyta loggar du in på Azure-portalen med det organisationskonto eller Microsoft-konto som du konfigurerade 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äsaren) och data lagras i en lokal cache 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 är märkta HTTPOnly och skyddas. Efter en förutbestämd inaktivitetsperiod avslutas Azure-portalsessionen.

Kundhanterade säkerhetsnycklar

Data i Azure Monitor krypteras med Microsoft-hanterade nycklar. Du kan använda kundhanterade krypteringsnycklar för att skydda data och sparade frågor på dina arbetsytor. Kundhanterade nycklar i Azure Monitor ger dig större flexibilitet att hantera åtkomstkontroller till dina loggar.

När du har konfigurerat krypteras nya data som matas in till länkade arbetsytor med din nyckel som lagras i Azure Key Vault eller Azure Key Vault Managed "HSM".

Privat lagring

Azure Monitor-loggar förlitar sig på Azure Storage i specifika scenarier. Använd privat/kundhanterad lagring för att hantera ditt personligt krypterade lagringskonto.

Med Azure Private Link-nätverk kan du på ett säkert sätt länka Azure Platform as a Service-tjänster (PaaS), inklusive Azure Monitor, till ditt virtuella nätverk med hjälp av privata slutpunkter.

Customer Lockbox för Microsoft Azure

Customer Lockbox för Microsoft Azure ger dig ett gränssnitt för att granska och godkänna eller avvisa begäranden om åtkomst till kunddata. Den används när en Microsoft-tekniker behöver komma åt kunddata, oavsett om det är ett svar på ett kundinitierat supportärende eller ett problem som identifierats av Microsoft. För att aktivera Customer Lockbox behöver du ett dedikerat kluster.

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.

Vanliga frågor och svar

Det här avsnittet innehåller svar på vanliga frågor.

Använder min agenttrafik min Azure ExpressRoute-anslutning?

Trafik till Azure Monitor använder ExpressRoute-kretsen för Microsoft-peering. I ExpressRoute-dokumentationen finns en beskrivning av de olika typerna av ExpressRoute-trafik.