Azure Monitor security overview and guidelines
This article provides Security guidelines for Azure Monitor as part of the Azure Well-Architected Framework.
Azure Monitor security guidelines help you understand the security features of Azure Monitor and how to configure them to optimize security based on:
- Cloud Adoption Framework, which provides security guidance for teams that manage the technology infrastructure.
- Azure Well-Architected Framework, which provides architectural best practices for building secure applications.
- Microsoft cloud security benchmark (MCSB), which describes the available security features and recommended optimal configurations.
- Zero Trust security principles, which provides guidance for security teams to implement technical capabilities to support a Zero Trust modernization initiative.
The guidelines in this article build on the Microsoft security responsibility model. As part of this model of shared responsibility, Microsoft provides these security measures for Azure Monitor customers:
- Azure infrastructure security
- Azure customer data protection
- Encryption of data in transit during data ingestion
- Encryption of data at rest with Microsoft managed keys
- Microsoft Entra authentication for data plane access
- Authentication of Azure Monitor Agent and Application Insights using managed identities
- Privileged access to data plane actions using Role-Based Access Control (Azure RBAC)
- Compliance with industry standards and regulations
Log ingestion and storage
Design checklist
- Configure access for different types of data in the workspace required for different roles in your organization.
- Use Azure private link to remove access to your workspace from public networks.
- Configure log query auditing to track which users are running queries.
- Ensure immutability of audit data.
- Determine a strategy to filter or obfuscate sensitive data in your workspace.
- Purge sensitive data that was accidentally collected.
- Link your workspace to a dedicated cluster for enhanced security features, including double encryption using customer managed keys and customer Lockbox for Microsoft Azure to approve or reject Microsoft data access requests.
- Use Transport Layer Security (TLS) 1.2 or higher to send data to your workspace using agents, connectors, and the Logs ingestion API.
Configuration recommendations
| Recommendation | Benefit |
|---|---|
| Configure access for different types of data in the workspace required for different roles in your organization. | Set the access control mode for the workspace to Use resource or workspace permissions to allow resource owners to use resource-context to access their data without being granted explicit access to the workspace. This simplifies your workspace configuration and helps to ensure users aren't able to access data they shouldn't. Assign the appropriate built-in role to grant workspace permissions to administrators at either the subscription, resource group, or workspace level depending on their scope of responsibilities. Apply table level RBAC for users who require access to a set of tables across multiple resources. Users with table permissions have access to all the data in the table regardless of their resource permissions. See Manage access to Log Analytics workspaces for details on the different options for granting access to data in the workspace. |
| Use Azure private link to remove access to your workspace from public networks. | Connections to public endpoints are secured with end-to-end encryption. If you require a private endpoint, you can use Azure private link to allow resources to connect to your Log Analytics workspace through authorized private networks. Private link can also be used to force workspace data ingestion through ExpressRoute or a VPN. See Design your Azure Private Link setup to determine the best network and DNS topology for your environment. |
| Configure log query auditing to track which users are running queries. | Log query auditing records the details for each query that's run in a workspace. Treat this audit data as security data and secure the LAQueryLogs table appropriately. Configure the audit logs for each workspace to be sent to the local workspace, or consolidate in a dedicated security workspace if you separate your operational and security data. Use Log Analytics workspace insights to periodically review this data and consider creating log search alert rules to proactively notify you if unauthorized users are attempting to run queries. |
| Ensure immutability of audit data. | Azure Monitor is an append-only data platform, but includes provisions to delete data for compliance purposes. You can set a lock on your Log Analytics workspace to block all activities that could delete data: purge, table delete, and table- or workspace-level data retention changes. However, this lock can still be removed. If you need a fully tamper-proof solution, we recommend you export your data to an immutable storage solution. Use data export to send data to an Azure storage account with immutability policies to protect against data tampering. Not every type of logs has the same relevance for compliance, auditing, or security, so determine the specific data types that should be exported. |
| Determine a strategy to filter or obfuscate sensitive data in your workspace. | You might be collecting data that includes sensitive information. Filter records that shouldn't be collected using the configuration for the particular data source. Use a transformation if only particular columns in the data should be removed or obfuscated. If you have standards that require the original data to be unmodified, then you can use the 'h' literal in KQL queries to obfuscate query results displayed in workbooks. |
| Purge sensitive data that was accidentally collected. | Check periodically for private data that might accidentally be collected in your workspace and use data purge to remove it. Data in tables with the Auxiliary plan can't currently be purged. |
| Link your workspace to a dedicated cluster for enhanced security features, including double encryption using customer managed keys and customer Lockbox for Microsoft Azure to approve or reject Microsoft data access requests. | Azure Monitor encrypts all data at rest and saved queries using Microsoft-managed keys (MMK). If you collect enough data for a dedicated cluster, use: - Customer-managed keys for greater flexibility and key lifecycle control. If you use Microsoft Sentinel, then make sure that you're familiar with the considerations at Set up Microsoft Sentinel customer-managed key. - Customer Lockbox for Microsoft Azure to review and approve or reject customer data access requests. Customer Lockbox is used when a Microsoft engineer needs to access customer data, whether in response to a customer-initiated support ticket or a problem identified by Microsoft. Lockbox can't currently be applied to tables with the Auxiliary plan. |
| Use Transport Layer Security (TLS) 1.2 or higher to send data to your workspace using agents, connectors, and the Logs ingestion API. | To ensure the security of data in transit to Azure Monitor, use Transport Layer Security (TLS) 1.2 or higher. Older versions of TLS/Secure Sockets Layer (SSL) have been found to be vulnerable and while they still currently work to allow backwards compatibility, they are not recommended, and the industry is quickly moving to abandon support for these older protocols. The PCI Security Standards Council has set a deadline of June 30, 2018 to disable older versions of TLS/SSL and upgrade to more secure protocols. Once Azure drops legacy support, if your agents can't communicate over at least TLS 1.3 you won't be able to send data to Azure Monitor Logs. We recommend you do NOT explicit set your agent to only use TLS 1.3 unless necessary. Allowing the agent to automatically detect, negotiate, and take advantage of future security standards is preferable. Otherwise you might miss the added security of the newer standards and possibly experience problems if TLS 1.3 is ever deprecated in favor of those newer standards. |
Alerts
Design checklist
- Use customer managed keys if you need your own encryption key to protect data and saved queries in your workspaces
- Use managed identities to increase security by controlling permissions
- Assign the monitoring reader role for all users who don’t need configuration privileges
- Use secure webhook actions
- When using action groups that use private links, use Event hub actions
Configuration recommendations
| Recommendation | Benefit |
|---|---|
| Use customer managed keys if you need your own encryption key to protect data and saved queries in your workspaces. | Azure Monitor ensures that all data and saved queries are encrypted at rest using Microsoft-managed keys (MMK). If you require your own encryption key and collect enough data for a dedicated cluster, use customer-managed keys for greater flexibility and key lifecycle control. If you use Microsoft Sentinel, then make sure that you're familiar with the considerations at Set up Microsoft Sentinel customer-managed key. |
| To control permissions for log search alert rules, use managed identities for your log search alert rules. | A common challenge for developers is the management of secrets, credentials, certificates, and keys used to secure communication between services. Managed identities eliminate the need for developers to manage these credentials. Setting a managed identity for your log search alert rules gives you control and visibility into the exact permissions of your alert rule. At any time, you can view your rule’s query permissions and add or remove permissions directly from its managed identity. In addition, using a managed identity is required if your rule’s query is accessing Azure Data Explorer (ADX) or Azure Resource Graph (ARG). See Managed identities. |
| Assign the monitoring reader role for all users who don’t need configuration privileges. | Enhance security by giving users the least amount of privileges required for their role. See Roles, permissions, and security in Azure Monitor. |
| Where possible, use secure webhook actions. | If your alert rule contains an action group that uses webhook actions, prefer using secure webhook actions for additional authentication. See Configure authentication for Secure webhook |
Virtual machine monitoring
Design checklist
- Use other services for security monitoring of your VMs.
- Consider using Azure private link for VMs to connect to Azure Monitor using a private endpoint.
Configuration recommendations
| Recommendation | Description |
|---|---|
| Use other services for security monitoring of your VMs. | While Azure Monitor can collect security events from your VMs, it isn't intended to be used for security monitoring. Azure includes multiple services such as Microsoft Defender for Cloud and Microsoft Sentinel that together provide a complete security monitoring solution. See Security monitoring for a comparison of these services. |
| Consider using Azure private link for VMs to connect to Azure Monitor using a private endpoint. | Connections to public endpoints are secured with end-to-end encryption. If you require a private endpoint, you can use Azure private link to allow your VMs to connect to Azure Monitor through authorized private networks. Private link can also be used to force workspace data ingestion through ExpressRoute or a VPN. See Design your Azure Private Link setup to determine the best network and DNS topology for your environment. |
Container monitoring
Design checklist
- Use managed identity authentication for your cluster to connect to Container insights.
- Consider using Azure private link for your cluster to connect to your Azure Monitor workspace using a private endpoint.
- Use traffic analytics to monitor network traffic to and from your cluster.
- Enable network observability.
- Ensure the security of the Log Analytics workspace supporting Container insights.
Configuration recommendations
| Recommendation | Benefit |
|---|---|
| Use managed identity authentication for your cluster to connect to Container insights. | Managed identity authentication is the default for new clusters. If you're using legacy authentication, you should migrate to managed identity to remove the certificate-based local authentication. |
| Consider using Azure private link for your cluster to connect to your Azure Monitor workspace using a private endpoint. | Azure managed service for Prometheus stores its data in an Azure Monitor workspace which uses a public endpoint by default. Connections to public endpoints are secured with end-to-end encryption. If you require a private endpoint, you can use Azure private link to allow your cluster to connect to the workspace through authorized private networks. Private link can also be used to force workspace data ingestion through ExpressRoute or a VPN. See Enable private link for Kubernetes monitoring in Azure Monitor for details on configuring your cluster for private link. See Use private endpoints for Managed Prometheus and Azure Monitor workspace for details on querying your data using private link. |
| Use traffic analytics to monitor network traffic to and from your cluster. | Traffic analytics analyzes Azure Network Watcher NSG flow logs to provide insights into traffic flow in your Azure cloud. Use this tool to ensure there's no data exfiltration for your cluster and to detect if any unnecessary public IPs are exposed. |
| Enable network observability. | Network observability add-on for AKS provides observability across the multiple layers in the Kubernetes networking stack. monitor and observe access between services in the cluster (east-west traffic). |
| Ensure the security of the Log Analytics workspace supporting Container insights. | Container insights relies on a Log Analytics workspace. See Best practices for Azure Monitor Logs for recommendations to ensure the security of the workspace. |