Gegevensbeveiliging van Azure Monitor-logboeken
In dit artikel wordt uitgelegd hoe Azure Monitor logboekgegevens verzamelt, verwerkt en beveiligt en beschrijft beveiligingsfuncties 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
- Incidenten beheren
- Naleving
- Certificeringen voor beveiligingsstandaarden
Neem contact met ons op met vragen, suggesties of problemen over een van de volgende informatie, waaronder ons beveiligingsbeleid op ondersteuning voor Azure opties.
Gegevens veilig verzenden met TLS
Om de beveiliging van gegevens in transit naar Azure Monitor te waarborgen, raden we u ten zeerst aan om de agent zo te configureren dat ten minste TLS 1.3 (Transport Layer Security) wordt gebruikt. 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 verplaatst om 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 heeft verloren, kunt u geen gegevens verzenden naar Azure Monitor-logboeken als uw agents niet kunnen communiceren via ten minste TLS 1.3.
Het is raadzaam om uw agent niet expliciet in te stellen op alleen TLS 1.3, tenzij dit nodig is. Het is raadzaam om de agent automatisch te laten detecteren, onderhandelen en profiteren van toekomstige beveiligingsstandaarden. Anders mist u mogelijk de extra beveiliging van de nieuwere standaarden en ondervindt u mogelijk problemen als TLS 1.3 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 | Ondersteund en standaard ingeschakeld. | Controleer of u nog steeds de standaardinstellingen gebruikt. |
| Windows Server 2012 - 2016 | Ondersteund en standaard ingeschakeld. | Bevestigen dat 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 door Azure Monitor zijn opgenomen, worden de gegevens logisch gescheiden gehouden voor elk onderdeel in de service. Alle gegevens worden per werkruimte gelabeld. Deze tagging blijft behouden gedurende de levenscyclus van 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 | Data types |
|---|---|
| Capaciteit en prestaties | Prestatiegegevens en metagegevens |
| Updatebeheer | Metagegevens en statusgegevens |
| Logboekbeheer | Door de gebruiker gedefinieerde gebeurtenislogboeken, Windows-gebeurtenislogboeken en/of IIS-logboeken |
| Wijzigingen bijhouden | Metagegevens van software-inventaris, Windows-service en Linux-daemon en metagegevens van Windows/Linux-bestanden |
| SQL- en Active Directory-evaluatie | WMI-gegevens, registergegevens, prestatiegegevens en resultaten van dynamische beheerweergave van SQL Server |
In de volgende tabel ziet u voorbeelden van gegevenstypen:
| Gegevenstype | Velden |
|---|---|
| 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, worden deze door Log Analytics verzameld. |
| 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 |
| Provincie | 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 uitgevoerd 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.
Incidenten beheren
Azure Monitor heeft een proces voor incidentbeheer dat alle Microsoft-services naleven. Om samen te vatten, doen we het volgende:
- 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
- Beoordeel de impact en ernst van een incident door een teamlid van een incident dat op oproep kan reageren. Op basis van bewijs kan de evaluatie wel of niet leiden tot verdere escalatie naar het beveiligingsresponsteam.
- Stel een incident vast door experts op het gebied van beveiligingsreacties om het technische of forensische onderzoek uit te voeren, insluiting te identificeren, te beperken en strategieën te omzeilen. Als het beveiligingsteam van mening is dat klantgegevens kunnen worden blootgesteld aan een onrechtmatige of niet-geautoriseerde persoon, begint parallelle uitvoering van het meldingsproces voor klantincidenten parallel.
- Stabiliseren en herstellen van het incident. Het reactieteam van het incident maakt een herstelplan om het probleem te verhelpen. Crisis insluitingsstappen, zoals het in quarantaine nemen van beïnvloede systemen, kunnen onmiddellijk en parallel aan 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 om beleid, procedures en processen te herzien om een terugkeer 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 een kennisgeving heeft
- Maak een kennisgeving om klanten gedetailleerde voldoende informatie te verstrekken, zodat ze een onderzoek kunnen uitvoeren aan hun kant en kunnen voldoen aan alle toezeggingen die ze aan hun eindgebruikers hebben gedaan, terwijl ze het meldingsproces niet per ongeluk 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 aan een of meer beheerders van een klant bezorgd door middel van microsoft-selecties, ook via e-mail.
- Teamgereedheid en training uitvoeren:
- Microsoft-medewerkers moeten de beveiligings- en bewustzijnstraining voltooien, zodat 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 zeldzaam is, meldt Microsoft elke klant binnen één dag als er aanzienlijk verlies van klantgegevens optreedt.
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-softwareontwikkelings- en serviceteam ondersteunt de bedrijfsvereisten en voldoet aan de wettelijke 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 ook daar beschreven. Jaarlijks bekijken we beleidsregels, standaarden, procedures en richtlijnen.
Elk lid van het ontwikkelteam 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 beveiligingsfunctionarissen hebben hun eigen beheerketen en voeren onafhankelijke evaluaties uit van producten en diensten om beveiliging en naleving te waarborgen.
De raad van bestuur van Microsoft wordt op de hoogte gesteld door een jaarverslag over alle informatiebeveiligingsprogramma's van Microsoft.
Het Log Analytics-softwareontwikkelings- en serviceteam werkt 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:
- ISO/IEC 27001
- ISO/IEC 27018:2014
- ISO 22301
- Payment Card Industry (PCI Compliant) Data Security Standard (PCI DSS) door de PCI Security Standards Council.
- SOC (Service Organization Controls) 1 Type 1 en SOC 2 Type 1 compatibel
- HIPAA en HITECH voor bedrijven met een HIPAA Business Associate Agreement
- Windows Common Engineering-criteria
- Microsoft Trustworthy Computing
- Als Azure-service voldoen de onderdelen die Azure Monitor gebruikt aan de nalevingsvereisten van Azure. Meer informatie vindt u in Microsoft Trust Center Compliance.
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 stroom van informatie van uw bedrijf en hoe deze wordt beveiligd als wordt verplaatst naar Azure Monitor, uiteindelijk gezien door u in Azure Portal. Meer informatie over elke stap volgt het diagram.
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 de Operations Manager-agent vanuit de beheergroep. Gebruikers (die u, andere individuele gebruikers of een groep personen 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 bij het beheren van gebruikerstoegang tot de gegevens. 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 regio van het datacenter.
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 van een Operations Manager-beheerserver naar de Azure Monitor-service verzonden, of vanwege het aantal gegevens dat door de agent 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 voor het genereren en onderhouden van sleutels. Persoonlijke sleutels worden elke 90 dagen geroteerd en worden opgeslagen in Azure en worden beheerd door de Azure-bewerkingen die strikte wettelijke en nalevingsprocedures 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 de beheerserver om welke reden dan ook niet kan communiceren met de service, worden de verzamelde gegevens lokaal opgeslagen in een tijdelijke cache op de beheerserver, wanneer een agent rapporteert aan een Operations Manager-beheergroep die is geïntegreerd met Azure Monitor. Ze proberen de gegevens om de 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 in de wachtrij geplaatst. Als de wachtrij vol raakt, begint de agent gegevenstypen te verwijderen, 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, worden deze verwijderd uit de cache.
Zoals hierboven beschreven, worden gegevens van de beheerserver of direct verbonden agents verzonden via TLS naar Microsoft Azure-datacenters. Desgewenst kunt u ExpressRoute 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 en maakt mijn agentverkeer gebruik van mijn Azure ExpressRoute-verbinding?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 Hubs 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 worden 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 ze worden verlengd tot 730 dagen. Gegevens worden versleuteld at-rest opgeslagen in Azure Storage, om vertrouwelijkheid van gegevens te garanderen en de gegevens worden gerepliceerd binnen de lokale regio met behulp van lokaal redundante opslag (LRS) of zone-redundante opslag (ZRS) in ondersteunde regio's. De laatste twee weken aan gegevens worden ook opgeslagen in ssd-cache en deze cache wordt versleuteld.
Gegevens in databaseopslag kunnen niet worden gewijzigd nadat 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 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 zijn gemarkeerd als HTTPOnly en zijn beveiligd. Na een vooraf bepaalde niet-actieve periode wordt de Azure Portal-sessie beëindigd.
Door de klant beheerde beveiligingssleutels
Gegevens in Azure Monitor worden versleuteld met door Microsoft beheerde sleutels. U kunt door de klant beheerde versleutelingssleutels gebruiken om de gegevens en opgeslagen query's in uw werkruimten te beveiligen. Door de klant beheerde sleutels in Azure Monitor bieden u meer flexibiliteit om toegangsbeheer voor uw logboeken te beheren.
Zodra de configuratie is uitgevoerd, worden nieuwe gegevens die zijn opgenomen in gekoppelde werkruimten versleuteld met uw sleutel die is opgeslagen in Azure Key Vault of beheerde HSM in Azure Key Vault.
Privé-opslag
Azure Monitor-logboeken zijn afhankelijk van Azure Storage in specifieke scenario's. Gebruik persoonlijke/door de klant beheerde opslag om uw persoonlijk versleutelde opslagaccount te beheren.
Private Link-netwerken
Met Azure Private Link-netwerken kunt u Met behulp van privé-eindpunten veilig PaaS-services (Platform as a Service) koppelen aan uw virtuele netwerk, waaronder Azure Monitor.
Klanten-lockbox voor Microsoft Azure
Customer Lockbox voor Microsoft Azure biedt u een interface voor het controleren en goedkeuren of afwijzen van aanvragen voor toegang tot klantgegevens. Deze wordt gebruikt wanneer een Microsoft-engineer toegang nodig heeft tot klantgegevens, of dit nu gebeurt als reactie op een door de klant geïnitieerd ondersteuningsticket of een probleem dat door Microsoft is geïdentificeerd. Als u Customer Lockbox wilt inschakelen, hebt u een toegewezen cluster nodig.
Controle op manipulatie en onveranderbaarheid
Azure Monitor is een gegevensplatform dat alleen kan worden toegevoegd, maar bevat voorzieningen 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, tabel verwijderen 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.
Veelgestelde vragen
In deze sectie vindt u antwoorden op veelgestelde vragen.
Maakt mijn agentverkeer gebruik van mijn Azure ExpressRoute-verbinding?
Verkeer naar Azure Monitor maakt gebruik van het ExpressRoute-circuit van Microsoft-peering. Zie de ExpressRoute-documentatie voor een beschrijving van de verschillende typen ExpressRoute-verkeer.