How to Secure your Network in Azure

Securing Network in Azure

All communication on Azure is over the public Internet by default. This leaves the infrastructure vulnerable to attacks as there is a much bigger attack window. Hence, your network in Azure needs to be secured by denying access over the public Internet and locking it down in a Virtual Network. Azure’s virtual network makes communication secure.

Virtual Network additionally allows:

  1. Communication with on-premises resources
  2. Filtering of Network traffic

All resources in a VNet can communicate outbound to the internet, by default by assigning a public IP address. To secure communication, the access needs to be locked by extending private address space using Service Endpoints. Service Endpoints ensure security by tying down communication only to that particular VNet.

When resources are in a VNet, they can be accessed in the following ways:

  1. Private Service Endpoint
  2. VNet Peering – You can connect virtual networks, enabling resources in either virtual network to communicate with each other. A low-latency, a high-bandwidth connection is established between resources in different virtual networks.

Private Service Endpoint

Private Service Endpoint provides secure and direct connectivity to Azure services over an optimized route over the backbone network in Azure . In simple terms, it establishes a Private link between 2 resources in a VNET. A Private Service Endpoint is deployed to a subnet within a VNet. It has several benefits:

  1. Optimal Routing – Traffic never goes to the public internet and stays on the Azure backbone.
  2. Less Organisational Overhead – Provides secure and direct connectivity to Azure services over an optimized route over the Azure backbone network. 
  3. Protection Against Data Leakage – Endpoint only exposes an instance of a PaaS resource. This ensures that connection is only to a specific resource instead of the entire service.

Establishing Communication between Storage Account and Databricks

  1. Databricks needs 2 dedicated subnets:
    • Public – allows communication with the Azure Databricks control pane
    • Private – allows only intra-cluster communication.
  2. Create Private Endpoint on Storage Account Blob Service.
  3. Add the endpoint to Private DNS.
  4. Deny Public Access of Storage Account
  5. Now the data-lake is accessible from that endpoint. To verify, perform the Unix command of nslookup on the storage account from Databricks. It should resolve to its Private IP address.
  6. Observation – VNet properly registers to Databricks only during resource creation
Securing Network in Azure

Establishing Secure Communication between Azure Data Factory and SQL Database

  1. Create Private Endpoints of both ADF and SQL Server
  2. Create a Virtual Network-enabled Integration Runtime for SQL
  3. ADF requests a managed Private Endpoint from SQL Server that needs to be approved from the Server
  4. Reflects in 1-2 mins in ADF

In short, the following steps can be taken to secure your network in Azure and the communication between a pair of resources in a VNet via a Private Link:

  1. Create VNet and Subnets, Private DNS
  2. Add Resources to VNet
  3. Establish Private Endpoint connections between resources
  4. Configure Private DNS With Connection
  5. Disable Public Access
Yash Tamakuwala
Latest posts by Yash Tamakuwala (see all)

What do you think?

Subscribed! We'll let you know when we have new blogs and events...