Gegevensbeveiliging van Azure Monitor-logboeken

In dit artikel wordt uitgelegd hoe Azure Monitor logboekgegevens verzamelt, verwerkt en beveiligt en beveiligingsfuncties beschrijft die u kunt gebruiken om uw Azure Monitor-omgeving verder te beveiligen. De informatie in dit artikel is specifiek voor Azure Monitor-logboeken en vormt een aanvulling op de informatie in het Vertrouwenscentrum van Azure.

Azure Monitor-logboeken beheren uw cloudgegevens veilig met behulp van:

  • Gegevensscheiding
  • Gegevensretentie
  • Fysieke beveiliging
  • Incidentbeheer
  • Naleving
  • Certificeringen voor beveiligingsstandaarden

Neem contact met ons op met vragen, suggesties of problemen over een van de volgende informatie, inclusief ons beveiligingsbeleid op ondersteuning voor Azure opties.

Gegevens veilig verzenden met TLS 1.2

Om de beveiliging van gegevens die worden verzonden naar Azure Monitor te garanderen, raden we u sterk aan om de agent te configureren voor het gebruik van ten minste TLS 1.2 (Transport Layer Security). Oudere versies van TLS/Secure Sockets Layer (SSL) zijn kwetsbaar gebleken en hoewel ze momenteel nog steeds werken om compatibiliteit met eerdere versies mogelijk te maken, worden ze niet aanbevolen en wordt de branche snel overgezet om de ondersteuning voor deze oudere protocollen te verlaten.

De PCI Security Standards Council heeft een deadline van 30 juni 2018 ingesteld om oudere versies van TLS/SSL uit te schakelen en een upgrade uit te voeren naar veiligere protocollen. Zodra Azure verouderde ondersteuning verliest, kunt u geen gegevens verzenden naar Azure Monitor-logboeken als uw agents niet kunnen communiceren via ten minste TLS 1.2.

U wordt aangeraden uw agent niet expliciet in te stellen op alleen TLS 1.2, tenzij dit absoluut noodzakelijk is. Het is beter om de agent toe te staan automatisch te detecteren, te onderhandelen en te profiteren van toekomstige beveiligingsstandaarden. Anders mist u mogelijk de toegevoegde beveiliging van de nieuwere standaarden en ondervindt u mogelijk problemen als TLS 1.2 ooit is afgeschaft ten gunste van deze nieuwere standaarden.

Platformspecifieke richtlijnen

Platform/taal Ondersteuning Meer informatie
Linux Linux-distributies zijn meestal afhankelijk van OpenSSL voor TLS 1.2-ondersteuning. Controleer het Changelog van OpenSSL om te bevestigen dat uw versie van OpenSSL wordt ondersteund.
Windows 8.0 - 10 Standaard ondersteund en ingeschakeld. Om te bevestigen dat u nog steeds de standaardinstellingen gebruikt.
Windows Server 2012 - 2016 Standaard ondersteund en ingeschakeld. Controleer of u nog steeds de standaardinstellingen gebruikt
Windows 7 SP1 en Windows Server 2008 R2 SP1 Ondersteund, maar niet standaard ingeschakeld. Zie de registerinstellingenpagina Transport Layer Security (TLS) voor meer informatie over het inschakelen.

Gegevensscheiding

Nadat uw gegevens zijn opgenomen door Azure Monitor, worden de gegevens logisch gescheiden gehouden voor elk onderdeel in de hele service. Alle gegevens worden per werkruimte getagd. Deze tagging blijft behouden gedurende de levenscyclus van de gegevens en wordt afgedwongen op elke laag van de service. Uw gegevens worden opgeslagen in een toegewezen database in het opslagcluster in de regio die u hebt geselecteerd.

Gegevensretentie

Geïndexeerde zoekgegevens voor logboeken worden opgeslagen en bewaard volgens uw prijsplan. Zie Prijzen voor Log Analytics voor meer informatie.

Als onderdeel van uw abonnementsovereenkomst behoudt Microsoft uw gegevens volgens de voorwaarden van de overeenkomst. Wanneer klantgegevens worden verwijderd, worden er geen fysieke stations vernietigd.

De volgende tabel bevat enkele van de beschikbare oplossingen en bevat voorbeelden van het type gegevens dat ze verzamelen.

Oplossing Gegevenstypen
Capaciteit en prestaties Prestatiegegevens en metagegevens
Updatebeheer Metagegevens en statusgegevens
Logboekbeheer Door de gebruiker gedefinieerde gebeurtenislogboeken, Windows-gebeurtenislogboeken en/of IIS-logboeken
Wijzigingen bijhouden Software-inventarisatie, Windows-service en Linux-daemonmetagegevens en metagegevens van Windows-/Linux-bestanden
SQL- en Active Directory-evaluatie WMI-gegevens, registergegevens, prestatiegegevens en SQL Server resultaten van dynamische beheerweergave

In de volgende tabel ziet u voorbeelden van gegevenstypen:

Gegevenstype Fields
Waarschuwing Waarschuwingsnaam, beschrijving van waarschuwing, BaseManagedEntityId, probleem-id, IsMonitorAlert, RuleId, ResolutionState, Prioriteit, Ernst, Categorie, Eigenaar, ResolvedBy, TimeRaised, TimeAdded, LastModified, LastModifiedBy, LastModifiedExceptRepeatCount, TimeResolved, TimeResolutionStateLastModified, TimeResolutionStateLastModifiedInDB, RepeatCount
Configuratie CustomerID, AgentID, EntityID, ManagedTypeID, ManagedTypePropertyID, CurrentValue, ChangeDate
Gebeurtenis EventId, EventOriginalID, BaseManagedEntityInternalId, RuleId, PublisherId, PublisherName, FullNumber, Number, Category, ChannelLevel, LoggingComputer, EventData, EventParameters, TimeGenerated, TimeAdded
Opmerking: Wanneer u gebeurtenissen schrijft met aangepaste velden in het Windows-gebeurtenislogboek, verzamelt Log Analytics deze.
Metagegevens BaseManagedEntityId, ObjectStatus, OrganizationalUnit, ActiveDirectoryObjectSid, PhysicalProcessors, NetworkName, IPAddress, ForestDNSName, NetbiosComputerName, VirtualMachineName, LastInventoryDate, HostServerNameIsVirtualMachine, IP-adres, NetbiosDomainName, LogicalProcessors, DNSName, DisplayName, DomainDnsName, ActiveDirectorySite, PrincipalName, OffsetInMinuteFromGreenwichTime
Prestaties ObjectName, CounterName, PerfmonInstanceName, PerformanceDataId, PerformanceSourceInternalID, SampleValue, TimeSampled, TimeAdded
Staat StateChangeEventId, StateId, NewHealthState, OldHealthState, Context, TimeGenerated, TimeAdded, StateId2, BaseManagedEntityId, MonitorId, HealthState, LastModified, LastGreenAlertGenerated, DatabaseTimeModified

Fysieke beveiliging

Azure Monitor wordt beheerd door Microsoft-personeel en alle activiteiten worden geregistreerd en kunnen worden gecontroleerd. Azure Monitor wordt beheerd als een Azure-service en voldoet aan alle Vereisten voor Naleving en beveiliging van Azure. U kunt details bekijken over de fysieke beveiliging van Azure-assets op pagina 18 van het Microsoft Azure-beveiligingsoverzicht. Fysieke toegangsrechten voor beveiligde gebieden worden binnen één werkdag gewijzigd voor iedereen die niet langer verantwoordelijk is voor de Azure Monitor-service, inclusief overdracht en beëindiging. U kunt lezen over de wereldwijde fysieke infrastructuur die we gebruiken in Microsoft Datacenters.

Incidentbeheer

Azure Monitor heeft een proces voor incidentbeheer waaraan alle Microsoft-services voldoen. Om samen te vatten, gaan we als volgende te werk:

  • Een model voor gedeelde verantwoordelijkheid gebruiken waarbij een deel van de beveiligingsverantwoordelijkheid deel uitmaakt van Microsoft en een deel van de klant is
  • Azure-beveiligingsincidenten beheren:
    • Een onderzoek starten bij het detecteren van een incident
    • De impact en ernst van een incident beoordelen door een teamlid van een incident op oproep. Op basis van bewijs kan de evaluatie wel of niet leiden tot verdere escalatie van het beveiligingsantwoordteam.
    • Stel een incident vast door experts op het gebied van beveiligingsreacties om het technische of forensische onderzoek uit te voeren, om insluitingsstrategieën, oplossingen en oplossingen te identificeren. Als het beveiligingsteam van mening is dat klantgegevens mogelijk zijn blootgesteld aan een onrechtmatige of onbevoegde persoon, begint parallelle uitvoering van het meldingsproces voor klantincidenten parallel.
    • Stabiliseren en herstellen van het incident. Het incidentresponsteam maakt een herstelplan om het probleem te verhelpen. Crisis-insluitingsstappen, zoals het afstoten van getroffen systemen, kunnen onmiddellijk en parallel met de diagnose plaatsvinden. Risicobeperking op langere termijn kan worden gepland die zich voordoen nadat het onmiddellijke risico is verstreken.
    • Sluit het incident en voer een post-mortem uit. Het incidentresponsteam maakt een post-mortem met een overzicht van de details van het incident, met de bedoeling beleidsregels, procedures en processen te herzien om een terugkeerpatroon van de gebeurtenis te voorkomen.
  • Klanten op de hoogte stellen van beveiligingsincidenten:
    • Het bereik van betrokken klanten bepalen en iedereen bieden die zo gedetailleerd mogelijk wordt beïnvloed
    • Maak een kennisgeving om klanten gedetailleerde informatie te geven, zodat ze een onderzoek kunnen uitvoeren aan hun kant en aan alle verplichtingen kunnen voldoen die ze aan hun eindgebruikers hebben gedaan, terwijl ze het meldingsproces niet onnodig vertragen.
    • Bevestig en declareer het incident, indien nodig.
    • Informeer klanten met een incidentmelding zonder onredelijke vertraging en in overeenstemming met enige juridische of contractuele toezegging. Meldingen van beveiligingsincidenten worden via e-mail bezorgd bij een of meer beheerders van een klant.
  • Teamgereedheid en training uitvoeren:
    • Microsoft-personeel moet beveiligings- en bewustzijnstraining voltooien, waarmee ze verdachte beveiligingsproblemen kunnen identificeren en rapporteren.
    • Operators die aan de Microsoft Azure-service werken, hebben aanvullende trainingsverplichtingen met betrekking tot hun toegang tot gevoelige systemen die klantgegevens hosten.
    • Medewerkers van Microsoft-beveiligingsreacties ontvangen gespecialiseerde training voor hun rollen

Hoewel dit zeer zeldzaam is, zal Microsoft elke klant binnen één dag op de hoogte stellen als er sprake is van aanzienlijk verlies van klantgegevens.

Zie Microsoft Azure Security Response in the Cloud voor meer informatie over hoe Microsoft reageert op beveiligingsincidenten.

Naleving

Het informatiebeveiligings- en governanceprogramma van het Azure Monitor-softwareontwikkelingsteam ondersteunt de bedrijfsvereisten en voldoet aan de wet- en regelgeving zoals beschreven in het Microsoft Azure Trust Center en Microsoft Trust Center Compliance. Hoe Azure Monitor-logboeken beveiligingsvereisten vastlegt, beveiligingscontroles identificeert, beheert en bewaakt, worden daar ook beschreven. Jaarlijks bekijken we beleidsregels, standaarden, procedures en richtlijnen.

Elk lid van het ontwikkelingsteam ontvangt formele training voor toepassingsbeveiliging. Intern gebruiken we een versiebeheersysteem voor softwareontwikkeling. Elk softwareproject wordt beveiligd door het versiebeheersysteem.

Microsoft heeft een beveiligings- en nalevingsteam dat alle services van Microsoft bewaakt en beoordeelt. Informatiebeveiligingsmedewerkers vormen het team en ze zijn niet gekoppeld aan de technische teams die Log Analytics ontwikkelen. De beveiligingsofficieren hebben hun eigen beheerketen en voeren onafhankelijke evaluaties uit van producten en services om beveiliging en naleving te garanderen.

De raad van bestuur van Microsoft wordt op de hoogte gesteld door een jaarverslag over alle informatiebeveiligingsprogramma's bij Microsoft.

Het Log Analytics-softwareontwikkelingsteam en -serviceteam werken actief samen met de Microsoft Legal and Compliance-teams en andere branchepartners om verschillende certificeringen te verkrijgen.

Certificeringen en attestations

Azure Log Analytics voldoet aan de volgende vereisten:

Notitie

In sommige certificeringen/attestations worden Azure Monitor-logboeken vermeld onder de voormalige naam van Operational Insights.

Beveiligingsgegevensstroom voor cloudcomputing

In het volgende diagram ziet u een cloudbeveiligingsarchitectuur als de gegevensstroom van uw bedrijf en hoe deze wordt beveiligd zoals wordt verplaatst naar Azure Monitor, die uiteindelijk door u in de Azure Portal wordt weergegeven. Meer informatie over elke stap volgt het diagram.

Afbeelding van gegevensverzameling en -beveiliging in Azure Monitor-logboeken

1. Registreren voor Azure Monitor en gegevens verzamelen

Voor het verzenden van gegevens naar Azure Monitor-logboeken configureert u een Windows- of Linux-agent die wordt uitgevoerd op virtuele Azure-machines of op virtuele of fysieke computers in uw omgeving of een andere cloudprovider. Als u Operations Manager gebruikt, configureert u vanuit de beheergroep de Operations Manager-agent. Gebruikers (die u, andere afzonderlijke gebruikers of een groep personen) kunnen zijn, maken een of meer Log Analytics-werkruimten en registreren agents met behulp van een van de volgende accounts:

Een Log Analytics-werkruimte is waar gegevens worden verzameld, geaggregeerd, geanalyseerd en gepresenteerd. Een werkruimte wordt voornamelijk gebruikt als een middel om gegevens te partitioneren en elke werkruimte is uniek. U wilt bijvoorbeeld uw productiegegevens laten beheren met één werkruimte en uw testgegevens die worden beheerd met een andere werkruimte. Werkruimten helpen een beheerder ook de gebruikerstoegang tot de gegevens te beheren. Aan elke werkruimte kunnen meerdere gebruikersaccounts zijn gekoppeld en elk gebruikersaccount heeft toegang tot meerdere Log Analytics-werkruimten. U maakt werkruimten op basis van de datacenterregio.

Voor Operations Manager brengt de Operations Manager-beheergroep een verbinding tot stand met de Azure Monitor-service. Vervolgens configureert u welke door agents beheerde systemen in de beheergroep gegevens mogen verzamelen en verzenden naar de service. Afhankelijk van de oplossing die u hebt ingeschakeld, worden gegevens van deze oplossingen rechtstreeks vanaf een Operations Manager-beheerserver verzonden naar de Azure Monitor-service, of vanwege het aantal gegevens dat door het door de agent beheerde systeem wordt verzameld, rechtstreeks van de agent naar de service verzonden. Voor systemen die niet worden bewaakt door Operations Manager, maakt elke systemen rechtstreeks verbinding met de Azure Monitorservice.

Alle communicatie tussen verbonden systemen en de Azure Monitor-service wordt versleuteld. Het TLS-protocol (HTTPS) wordt gebruikt voor versleuteling. Het Microsoft SDL-proces wordt gevolgd om ervoor te zorgen dat Log Analytics up-to-date is met de meest recente ontwikkelingen in cryptografische protocollen.

Elk type agent verzamelt logboekgegevens voor Azure Monitor. Het type gegevens dat wordt verzameld, is afhankelijk van de configuratie van uw werkruimte en andere functies van Azure Monitor.

2. Gegevens verzenden van agents

U registreert alle agenttypen met een inschrijvingssleutel en er wordt een beveiligde verbinding tot stand gebracht tussen de agent en de Azure Monitor-service met behulp van verificatie op basis van certificaten en TLS met poort 443. Azure Monitor maakt gebruik van een geheim archief om sleutels te genereren en te onderhouden. Persoonlijke sleutels worden elke 90 dagen gedraaid en worden opgeslagen in Azure en worden beheerd door de Azure-bewerkingen die strikte regelgeving en nalevingspraktijken volgen.

Met Operations Manager brengt de beheergroep die is geregistreerd bij een Log Analytics-werkruimte een beveiligde HTTPS-verbinding tot stand met een Operations Manager-beheerserver.

Voor Windows- of Linux-agents die worden uitgevoerd op virtuele Azure-machines, wordt een alleen-lezen opslagsleutel gebruikt voor het lezen van diagnostische gebeurtenissen in Azure-tabellen.

Als een agent om welke reden dan ook niet kan communiceren met de service, worden de verzamelde gegevens lokaal opgeslagen in een tijdelijke cache op de beheerserver als deze niet kan communiceren met de service. Ze proberen de gegevens elke acht minuten gedurende twee uur opnieuw te verzenden. Voor gegevens die de beheerserver omzeilen en rechtstreeks naar Azure Monitor worden verzonden, is het gedrag consistent met de Windows-agent.

De gegevens in de cache van de Windows- of beheerserveragent worden beveiligd door het referentiearchief van het besturingssysteem. Als de service de gegevens na twee uur niet kan verwerken, worden de gegevens door de agents in de wachtrij geplaatst. Als de wachtrij vol raakt, begint de agent met het verwijderen van gegevenstypen, te beginnen met prestatiegegevens. De limiet voor de agentwachtrij is een registersleutel, zodat u deze indien nodig kunt wijzigen. Verzamelde gegevens worden gecomprimeerd en verzonden naar de service, waarbij de Operations Manager-beheergroepdatabases worden overgeslagen, zodat er geen belasting aan wordt toegevoegd. Nadat de verzamelde gegevens zijn verzonden, wordt deze verwijderd uit de cache.

Zoals hierboven beschreven, worden gegevens van de beheerserver of direct verbonden agents via TLS verzonden naar Microsoft Azure-datacenters. U kunt ExpressRoute desgewenst gebruiken om extra beveiliging voor de gegevens te bieden. ExpressRoute is een manier om rechtstreeks verbinding te maken met Azure vanuit uw bestaande WAN-netwerk, zoals een MPLS-VPN (Multi Protocol Label Switching) dat wordt geleverd door een netwerkserviceprovider. Zie ExpressRoute voor meer informatie.

3. De Azure Monitor-service ontvangt en verwerkt gegevens

De Azure Monitor-service zorgt ervoor dat binnenkomende gegevens afkomstig zijn van een vertrouwde bron door certificaten en de gegevensintegriteit met Azure-verificatie te valideren. De niet-verwerkte onbewerkte gegevens worden vervolgens opgeslagen in een Azure Event Hub in de regio waar de gegevens uiteindelijk in rust worden opgeslagen. Het type gegevens dat wordt opgeslagen, is afhankelijk van de typen oplossingen die zijn geïmporteerd en gebruikt voor het verzamelen van gegevens. Vervolgens verwerkt de Azure Monitor-service de onbewerkte gegevens en neemt deze op in de database.

De bewaarperiode van verzamelde gegevens die zijn opgeslagen in de database, is afhankelijk van het geselecteerde prijsplan. Voor de gratis laag zijn verzamelde gegevens zeven dagen beschikbaar. Voor de betaalde laag zijn verzamelde gegevens standaard 31 dagen beschikbaar, maar kunnen worden verlengd tot 730 dagen. Gegevens worden versleuteld at rest opgeslagen in Azure Storage, om de vertrouwelijkheid van gegevens te garanderen en de gegevens worden gerepliceerd in de lokale regio met behulp van lokaal redundante opslag (LRS). De laatste twee weken aan gegevens worden ook opgeslagen in ssd-cache en deze cache is versleuteld.

Gegevens in databaseopslag kunnen niet worden gewijzigd zodra ze zijn opgenomen, maar kunnen worden verwijderd via het opschonings-API-pad. Hoewel gegevens niet kunnen worden gewijzigd, vereisen sommige certificeringen dat gegevens onveranderbaar worden bewaard en niet kunnen worden gewijzigd of verwijderd in de opslag. Onveranderbaarheid van gegevens kan worden bereikt met behulp van gegevensexport naar een opslagaccount dat is geconfigureerd als onveranderbare opslag.

4. Azure Monitor gebruiken om toegang te krijgen tot de gegevens

Als u toegang wilt krijgen tot uw Log Analytics-werkruimte, meldt u zich aan bij de Azure Portal met het organisatieaccount of Het Microsoft-account dat u eerder hebt ingesteld. Al het verkeer tussen de portal en de Azure Monitor-service wordt verzonden via een beveiligd HTTPS-kanaal. Wanneer u de portal gebruikt, wordt er een sessie-id gegenereerd op de gebruikersclient (webbrowser) en worden gegevens opgeslagen in een lokale cache totdat de sessie wordt beëindigd. Wanneer de cache is beëindigd, wordt de cache verwijderd. Cookies aan de clientzijde, die geen persoonsgegevens bevatten, worden niet automatisch verwijderd. Sessiecookies worden gemarkeerd als HTTPOnly en zijn beveiligd. Na een vooraf bepaalde niet-actieve periode wordt de Azure Portal sessie beëindigd.

Aanvullende beveiligingsfuncties

U kunt deze extra beveiligingsfuncties gebruiken om uw Azure Monitor-omgeving verder te beveiligen. Voor deze functies is meer beheerdersbeheer vereist.

  • Door de klant beheerde sleutels (beveiliging): u kunt door de klant beheerde sleutels gebruiken om gegevens te versleutelen die naar uw Log Analytics-werkruimten worden verzonden. Hiervoor is het gebruik van Azure Key Vault vereist.
  • Privé-/door de klant beheerde opslag : beheer uw persoonlijk versleutelde opslagaccount en vertel Azure Monitor dat deze moet worden gebruikt om bewakingsgegevens op te slaan
  • Private Link netwerken: met Azure Private Link kunt u Azure PaaS-services (inclusief Azure Monitor) veilig koppelen aan uw virtuele netwerk met behulp van privé-eindpunten.
  • Azure Customer Lockbox - Customer Lockbox voor Microsoft Azure biedt klanten een interface voor het beoordelen en goedkeuren of afwijzen van aanvragen voor toegang tot klantgegevens. Dit wordt gebruikt in gevallen waarin een Microsoft-engineer toegang heeft tot klant gegevens tijdens een ondersteuningsaanvraag.

Manipulatie-controle en onveranderbaarheid

Azure Monitor is een gegevensplatform dat alleen kan worden toegevoegd, maar bevat bepalingen voor het verwijderen van gegevens voor nalevingsdoeleinden. U kunt een vergrendeling instellen voor uw Log Analytics-werkruimte om alle activiteiten te blokkeren die gegevens kunnen verwijderen: opschonen, verwijderen van tabellen en wijzigingen in gegevensretentie op tabel- of werkruimteniveau. Deze vergrendeling kan echter nog steeds worden verwijderd.

Als u uw bewakingsoplossing volledig wilt knoeien, raden we u aan uw gegevens te exporteren naar een onveranderbare opslagoplossing.

Volgende stappen