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 onderweg zijn naar Azure Monitor te garanderen, raden we u ten zeerst aan om de agent zo te configureren dat ten minste TLS (Transport Layer Security) 1.2 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.2.
Het is raadzaam om 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 extra 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 | Ondersteund en standaard ingeschakeld. | Om te bevestigen dat u nog steeds de standaardinstellingen gebruikt. |
| Windows Server 2012 - 2016 | Ondersteund en standaard ingeschakeld. | Controleren 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 service. Alle gegevens worden gelabeld per werkruimte. 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 Log Analytics-prijzen 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 | 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 SQL Server resultaten van dynamische beheerweergave |
In de volgende tabel ziet u voorbeelden van gegevenstypen:
| Gegevenstype | Fields |
|---|---|
| Waarschuwing | Waarschuwingsnaam, waarschuwingsbeschrijving, BaseManagedEntityId, probleem-id, IsMonitorAlert, RuleId, ResolutionState, Priority, Ernst, Categorie, Eigenaar, ResolvedBy, TimeRaised, TimeAdded, LastModified, LastModifiedBy, LastModifiedExceptRepeatCount, TimeResolved, TimeResolutionStateLastModified, TimeResolutionStateLastModifiedInDB, RepeatCount |
| Configuration | 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. Samenvattend:
- 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:
- Startmenu een onderzoek naar de detectie van een incident
- Beoordeel de impact en ernst van een incident door een teamlid van het incident dat on-call wordt uitgevoerd. Op basis van bewijs kan de evaluatie wel of niet leiden tot verdere escalatie naar het beveiligingsantwoordteam.
- Stel een incident vast door experts op het gebied van beveiligingsrespons om het technische of forensische onderzoek uit te voeren, insluitingsstrategieën, oplossingen en tijdelijke oplossingen te identificeren. Als het beveiligingsteam denkt dat klantgegevens mogelijk worden blootgesteld aan een onrechtmatige of niet-geautoriseerde persoon, begint de 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 containment-stappen, zoals de in quarantaine getroffen 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 beleid, procedures en processen te herzien om een herhaling 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 informatie te geven, zodat ze een onderzoek kunnen uitvoeren naar hun eind 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 overeenkomstig enige juridische of contractuele toezegging. Meldingen van beveiligingsincidenten worden via e-mail bezorgd bij een of meer van de beheerders van een klant.
- Teamgereedheid en training uitvoeren:
- Microsoft-personeel is vereist om de training voor beveiliging en bewustzijn te 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 zeer zeldzaam, zal Microsoft elke klant binnen één dag op de hoogte stellen als er aanzienlijk verlies van klantgegevens optreedt.
Zie Microsoft Azure Beveiligingsreactie in de 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 wet- en regelgeving zoals beschreven in Microsoft Azure Vertrouwenscentrum en Microsoft Trust Center Compliance. Hoe Azure Monitor-logboeken beveiligingsvereisten vastlegt, beveiligingscontroles identificeert, beheert en bewaakt, worden daar ook beschreven. Jaarlijks beoordelen we beleidsregels, standaarden, procedures en richtlijnen.
Elk lid van het ontwikkelingsteam ontvangt formele toepassingsbeveiligingstraining. Intern gebruiken we een versiebeheersysteem voor softwareontwikkeling. Elk softwareproject wordt beveiligd door het versiebeheersysteem.
Microsoft heeft een beveiligings- en nalevingsteam dat toezicht houdt op en beoordeelt alle services van Microsoft. 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 services om de beveiliging en naleving te waarborgen.
De raad van bestuur van Microsoft wordt op de hoogte gesteld door een jaarverslag over alle informatiebeveiligingsprogramma's bij Microsoft.
Het softwareontwikkelings- en serviceteam van Log Analytics werkt actief samen met de Microsoft Legal and Compliance-teams en andere branchepartners om verschillende certificeringen te verkrijgen.
Certificeringen en attestaties
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 conform
- HIPAA en HITECH voor bedrijven met een HIPAA Business Associate Agreement
- algemene technische criteria voor Windows
- 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 gegevensstroom van uw bedrijf en hoe deze wordt beveiligd, zoals wordt verplaatst naar Azure Monitor, uiteindelijk gezien door u in de Azure Portal. Meer informatie over elke stap volgt het diagram.

1. Registreren voor Azure Monitor en gegevens verzamelen
Voor uw organisatie om gegevens te verzenden 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:
In een Log Analytics-werkruimte worden gegevens 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 vanaf een Operations Manager-beheerserver verzonden naar de Azure Monitor-service of door het volume aan 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 van agents verzenden
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 geheimarchief 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 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 om diagnostische gebeurtenissen in Azure-tabellen te lezen.
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 de agent om welke reden dan ook niet kan communiceren met een Operations Manager-beheergroep die is geïntegreerd met Azure Monitor. 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 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 uit de cache verwijderd.
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), 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 om gegevens te verzamelen. 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 binnen de lokale regio met behulp van lokaal redundante opslag (LRS). De laatste twee weken aan gegevens worden ook opgeslagen in op SSD gebaseerde cache en deze cache is versleuteld.
Gegevens in databaseopslag kunnen niet worden gewijzigd nadat ze zijn opgenomen, maar kunnen worden verwijderd via het pad van de opschonings-API. Hoewel gegevens niet kunnen worden gewijzigd, vereisen sommige certificeringen dat gegevens onveranderbaar blijven 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
Voor toegang tot uw Log Analytics-werkruimte meldt u zich aan bij de Azure Portal met het organisatieaccount of 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 een interface voor klanten om aanvragen voor klantgegevenstoegang te beoordelen en goed te keuren of af te wijzen. 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 alleen-toevoegend gegevensplatform dat bepalingen bevat voor het verwijderen van gegevens voor nalevingsdoeleinden. Stel een vergrendeling in 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.
Als u uw bewakingsoplossing wilt knoeien, raden we u aan om gegevens te exporteren naar een onveranderbare opslagoplossing.