Architectural Guidance – Azure Monitor private links with Microsoft Sentinel

This article is contributed. See the original author and article here.

Firstly, I would like to thank  Benjamin Kovacevic for his help with this article.

 

In this blog post, I will try to simplify one of the confusions and a popular question seen by many organizations around the ability to use private links together with Microsoft Sentinel.

 

Starting with basics:

 

Microsoft Sentinel

Microsoft Sentinel is a cloud-native SIEM solution that is built on top of the log analytics workspace and hence, Microsoft Sentinel requires data to be ingested into that same log analytics workspace for its operation.

 

Log analytics workspace

Log analytics workspace is a native Azure monitoring resource that is part of Azure monitor as Azure monitor contains also resources like application insights and DCR resources and so on.

 

Microsoft Sentinel log source types

Microsoft Sentinel log sources are either:

 

• Diagnostic-based data sources: This type covers data ingested through the diagnostic settings from Azure PaaS and/or Saas services. Examples like: Activity logs, Azure AD audit logs, Azure Data factories, Key vaults, and so on. Once configured, data starts to flow from the Azure resource to the log analytics workspace.

• Service-to-service data integration: This type covers direct connections from other Microsoft services like Defender for Endpoint, Defender for Cloud, Defender for Office365, and so on. Once the connection is turned on, data starts to flow automatically through the Azure backend to the log analytics workspace.

• Agent-based-ingestion log sources: This covers all ingestion that is based on either AMA or LAA (MMA) agents. Data sources could be VMs that are running in Azure, on-premises, or in other cloud platforms.

• REST API based ingestion: This covers data ingestion and queries through pipelines line LogicApp connectors, Function Apps, and some 3^rd party connectors in Microsoft Sentinel.

 

Azure Monitor Private link

Private link in Azure Monitor is a network restriction and security mechanism that could be used to force traffic to flow only through private connections from a VNET to an azure monitor resource. In this context, we will focus on log analytics workspace as our Azure monitor resource.

 

Type1: Ingesting data through diagnostic settings

As mentioned in this document under exception section, data ingested through diagnostic settings pipeline by default go over a secure private channel and is not impacted by private links.

 

 

The same goes for type2 service-to-service data integrations as they also flow through Azure backbone.

 

Type3: Agent-based-ingestion log sources

The best way to look at the concept under the context of this type3 is to examine the following diagram taken from this document

 

 

Note that On-premises here could also be replaced by VNETs on azure as well because the same concept applies.

 

So the idea is simply that traffic from on-premises (or any VNET on Azure) will communicate to the private endpoint IP address that is associated with the private link scope object.

Fact 1: This basically means that it primarily depends on how DNS is configured.

Fact 2: On the workspace level, an On/Off setting exists to control whether to accept data ingestion not originating from private link scope or not.

Fact 3: On the workspace level, an On/Off setting exists to control whether to accept log queries not originating from private link scope or not.

Fact 4: The private link scope could be covering all log analytic workspaces or some of them. At this point, we need to pay attention to the private link mode (private only or open).

Private only mode: allows the traffic VNet to only reach resources in the link scope. traffic to log analytics workspace out of the link scope is blocked.

Open mode: allows the VNet to reach log analytic workspaces that are covered by the private link scope AND log analytics workspaces that are not covered by the private link scope. (if they accept traffic from public networks). The Open mode is useful for a mixed mode of work (accessing some resources publicly and others over a Private Link), or during a gradual onboarding process.

 

So to simplify it, the following matrix should give an idea of how the result looks like for interactions between these four items. For other workspaces that are not covered by the same link scope, the following matrix applies

 

link scope mode	Workspace Setting: Accept data ingestion from public networks not connected through a Private Link Scope	Outcome
		Public traffic
Private only	On	Blocked
Private only	Off	Blocked
Open	On	Allowed
Open	Off	Blocked

 

As expected, any log ingestion traffic for log analytics workspaces that are not covered by the same private link scope will be denied and only allowed if the link scope mode is set to Open

 

Our Recommendations from the field

 

• Considering Azure monitor private link should be associated with either a concrete requirement or certain compliance obligations.


• Use link mode: open when newly onboarding Microsoft Sentinel and switch to link mode: private only mode only after careful assessment of implication on all log analytics workspaces that are available and assessment of network and DNS design.

Brought to you by Dr. Ware, Microsoft Office 365 Silver Partner, Charleston SC.