In the vast realm of cloud computing, Azure Synapse stands tall as a game-changer, offering unmatched analytics service capabilities. But with great power comes great responsibility, especially when it comes to networking. To some, navigating Azure Synapse Networking might feel like deciphering a complex maze. But here’s the good news! This blog is your compass, designed to demystify the enigmas, streamline the complexities, and illuminate the core essence of Azure Synapse Networking. Whether you’re an Azure aficionado or a newcomer exploring cloud analytics, this guide is your ticket to a transformative experience.

Default Deployment of Synapse and Public Traffic

When you first deploy Azure Synapse, it’s set up to allow public traffic by default. This means that any user with the right credentials can access the Synapse workspace from anywhere in the world. While this offers ease of access, it might not be the most secure setup for all businesses.

Azure Synapse networking and Private Endpoint

For those seeking an added layer of security, Azure Synapse provides the option of a private endpoint. This ensures that the Synapse workspace is accessible only within a specific virtual network, adding a robust layer of protection against potential external threats.

Azure Private Endpoint is a network interface that connects you privately and securely to a service powered by Azure Private Link. Private Endpoint uses a private IP address from your VNet, effectively bringing the service into your VNet.

In short, you can access a public service using a private endpoint. Your request goes through a redirection to a private IP. Every Synapse workspace comes with a few endpoints which are used to connect to various applications:

If we take the dedicated SQL endpoint for example and we add a private endpoint. What’s basically happening is when you connect to it, your request goes through a redirection to a private IP. If you do a nslookup to the SQL endpoint, you can see it routes to the private endpoint:

Accessing ADLS Insecurely

Azure Data Lake Storage (ADLS) is a frequent companion to Synapse. However, accessing ADLS without the right security measures can expose sensitive data. Insecure access typically means data is vulnerable to interception during transit.

ADLS Access Secure way

The secure way to access ADLS involves using private endpoints inside virtual networks. This ensures that only authorized entities can access the data, and even then, the data is encrypted during transit.

But how can Synapse Access ADLS Securely?

You might be thinking about how Synapse can access ADLS securely because it is not depicted here. The answer is by using managed private endpoints Synapse can access ADLS. This ensures a direct, secure connection between Synapse and ADLS without exposing the data to the public internet.

In the below diagram, Synapse uses a managed private endpoint for outbound traffic to ADLS Gen2.

Synapse Exfiltration Protection

Data exfiltration is a significant concern for many businesses. Azure Synapse offers features like exfiltration protection to ensure that requests don’t unintentionally leave the secure environment outside the synapse.

By default, Synapse can access an external URL to fetch data. An example could be to fetch Data from the NYC cab data set from an external URL. If we do not want Synapse to fetch any external URL the solution would be to block any external URL and that is called Synapse exfiltration protection.

In the diagram below we have restricted Synapse to access storage account from another tenant.

This is how you enable synapse Exfiltration while creating the synapse workspace in the networking tab.

Synapse Managed VNet and Managed Private Endpoint

Azure Synapse provides a managed VNet (Virtual Network) to ensure a secure and isolated environment. The Managed Private Endpoint further ensures that Synapse can securely access other Azure services without exposing the data.

Synapse uses a managed VNET / Subnet (i.e. not a customer’s one) and exposes private endpoints in customers’ VNETs as needed. This is the reason you never pick a VNET in the wizard during the creation.

Since VNET belongs to Microsoft and is managed, it is isolated by itself. It therefore requires private endpoints from other PaaS to be created into it.

Synapse Private Link Hub

When you connect to Azure Synapse this URL is being used: web.azuresynapse.net. But this is a public URL and you do not want to access this Public URL instead you want to create a private endpoint to this URL so it is available in your own Vnet. That is exactly what Synapse Private Link Hub does. With Synapse Private link you make this public URL accessible to your VNet.

Synapse Secure Architecture

In essence, the Azure Synapse architecture is designed with security at its core. From default deployments to advanced features like the Private Link Hub, every aspect is crafted to ensure data integrity, security, and efficient analytics. In this diagram, we have shown all the features described above.

Conclusion

In our exploration of Azure Synapse Networking, we’ve journeyed from its foundational default deployments to the intricacies of private endpoints. We’ve tackled the challenges of accessing ADLS securely and delved into the mechanisms that ensure Synapse’s safe interaction with ADLS. The spotlight on Synapse’s exfiltration protection and the introduction of managed VNet and Managed Private Endpoint further emphasized the platform’s dedication to robust security. The Private Link Hub, acting as a nexus for secure data flow, and the overarching architecture of Azure Synapse Networking, have showcased the platform’s comprehensive approach to cloud analytics. As we wrap up, it’s evident that Azure Synapse Networking is a meticulously crafted system, designed to offer both functionality and security. This guide aimed to demystify its components, and we hope it served as a valuable compass in your Azure Synapse Networking adventure.