Network Security: Azure Private Endpoint and Private Link

FEATURED On-Demand Webinar

The Fundamentals of Zero Trust and Securing Your Data

Join our solutions experts as we discuss the 5 Ws and the H of Establishing Zero Trust for your organization.

Watch the On-Demand Webinar

Microsoft customers have been asking for improvements and guidance for years to ensure Microsoft Platform as a Service (PaaS) services are secure yet available for their applications without having to manage endless NSGs (Network Security Groups), resource firewalls, or access lists across the enterprise.

Enter Azure Private Link. Private Link is an offering that includes two components: Private Endpoint and Private Link Service. Private Endpoint lets you configure a private IP address endpoint for your PaaS applications while allowing your internal resources and customers to connect to it over your VPN or peered networks. This eliminates the need for the service to be publicly available and no longer requires taxing administration of NSGs, PaaS firewalls, or customer IP lists. Traffic to these private endpoints traverses the Microsoft backbone network without ever touching the public Internet.

The Azure Private Link Service takes this a step further, allowing you to extend your Private Endpoints to business partners or customers. This service requires an approval process as an added layer of security to prevent unintended access to your internal resources.

Benefits of Private Link/Endpoint Service

The primary benefit of the Azure Private Link is that it eliminates a huge hurdle for some organizations that are bound by compliance or governance requirements that traffic is privately secured throughout the organization. Now those organizations can connect to private endpoints via site-to-site VPN or ExpressRoute, fulfilling security requirements for available PaaS Services without having to traverse the public Internet.

Private Link also benefits from private DNS and IP addressing. This allows you to manage and maintain your private IP spaces and internal DNS systems without requiring public IP or DNS updates which are often are handled by external parties. This scenario also alleviates complex routing rules that would have internal apps sending PaaS services requests out to the Internet. Now those calls can be sent internally.

Each private endpoint is linked to the specific instance of the PaaS resource it represents to prevent data leakage. This means that each private endpoint only facilitates access to the SQL Server, storage account, or web app to which it is linked. In this manner, data leakage is greatly reduced as applications and resources must reference the specific service and instance combination, rather than the entire service.

Extending internal resources to other departments or customers is another key benefit of Private link. Using Private Link in parallel with Azure Standard Load Balancer enables you to make internal PaaS or IaaS services available via Private Endpoint to business units or external customers without allowing traffic to or from the Internet. This is called the Private Link Service.

Logging and Monitoring

As with many Azure resources, logging and monitoring strategies are an important consideration in Azure Private Link as well. However, in this case, we are not talking about monitoring the private endpoints as resources but rather, how we can use Private Link to facilitate monitoring within an existing Azure environment.

The Azure Monitor Private Link Scope (AMPLS) was designed to enable access to Azure monitor privately. This solution uses the Private Link Service to enable Azure monitoring for a specific scope of backend resources. The monitoring solution can send logging and diagnostic information directly to a private endpoint scoped to the designated Log Analytics Workspace (and other components) rather than the general Azure Monitor public endpoint, eliminating the need for many resources to have access to the public Internet. This can be seen in figure 1 below. This has the added benefit of ensuring that logs for your application are only accessible via a private endpoint.

Example of Azure Monitor Private Link Scoping.

Fig 1: Example of Azure Monitor Private Link Scoping. Credit Microsoft Docs

When designing the AMPLS, consider where it should live and what resources should be accessible via the private link scope. If you’re using a shared services model with a central hub network, consider placing the AMPLS in the hub network and scoping coverage to all monitoring infrastructure covered by the hub and spoke networks. An example of this can be seen in Figure 2 below

Example of shared services model for AMPLS.

Fig 2: Example of shared services model for AMPLS. Credit Microsoft Docs

Using Azure’s Private Link Service

Thus far we have referred to Azure’s Private Link as a service, so the idea of introducing a new concept Private Link Service may be a little confusing. Believe me, you’re not alone! Private Link Service refers to the idea of making your internal Private Link service available for another business unit or customer to consume via private endpoint.

The Private Link Service pairs your internal service or application with a Standard Load Balancer that allows access from parties outside your network. Access is restricted via RBAC (within the same tenant), subscription, or alias. The customer can then create a private endpoint and request access to the Private Link Service via an approval process. n this way, businesses can utilize completely private network components without the trouble or security considerations of maintaining VPN connectivity or peering to the consumers of their application.

Azure Private Link Service being consumed by a customer in another network.

Fig 3: Azure Private Link Service being consumed by a customer in another network. Credit Microsoft Docs

Private Endpoint Considerations

There are many considerations before diving in and rolling out private endpoints or any other services discussed here. Some of the questions I typically ask during discovery sessions with clients include:

Does your app or service require networking components at all?

Many resource types do not require a private virtual network to function. Adding this overhead can be problematic for some organizations and increase the administrative workload needlessly.

Do you need to connect to this app from your on-premises network, from outside Azure, or from user workstations?

This answer may influence where and how you implement private endpoint resources.

Does your business have any compliance or security requirements to communicate only over private networks?

Do you currently utilize NSGs and/or UDRs?

NSG and UDR resources are currently bypassed by traffic flowing out of a private endpoint. A preview solution is available to work around this limitation. Currently, these limitations pose complex routing challenges for solutions like Databricks and the like.

FAQs

How Hitachi Helps

Hitachi Solutions has helped hundreds of clients leverage Azure to secure their applications. Our experienced cloud security practitioners understand the challenges, as well as the potential, of Azure security and are here to help assess, plan, and implement your next-gen security strategy.