Azure Synapse Analytics Security Guide

An Azure Synapse Analytics workspace brings SQL pools, Spark, pipelines and dozens of linked data sources under one roof, so the way it is set up decides how far a single identity or credential can reach. Synapse access is controlled in three layers that work together: Azure RBAC for the resource, Synapse RBAC for the workspace and its artifacts, and SQL permissions inside each pool. Two of the strongest network controls, the managed virtual network and data exfiltration protection, can only be chosen when the workspace is created. This guide covers identity and roles, linked service credentials, network isolation, logging and a hardening baseline, plus the security points to carry into a move to Microsoft Fabric. It is written for data platform engineers, cloud security teams and architects running or planning Synapse workspaces.

This is an independent guide from NHI Mgmt Group, based on Microsoft's public Azure Synapse Analytics documentation as of November 2026. It is not sponsored or reviewed by Microsoft. Product features change, so confirm settings against Microsoft's current documentation.

Key takeaways

Decide network isolation at creation. The managed virtual network and data exfiltration protection cannot be added or removed after a workspace exists, so make the choice before the first deployment.
Use three layers of access on purpose. Azure RBAC creates pools and runtimes, Synapse RBAC governs code, artifacts and credentials, and SQL permissions govern data in each pool.
Treat Synapse Credential User as privileged. It lets the holder use secrets behind linked services and the workspace managed identity, which is effectively access to every source those credentials reach.
Keep secrets in Key Vault and identities managed. Reference linked service secrets from Azure Key Vault and prefer the workspace managed identity over stored keys and passwords.
Turn on Microsoft Entra-only authentication. Use a security group as the Microsoft Entra admin and disable the SQL administrator login so every SQL connection is tied to an Entra identity.

How identity and access work in Azure Synapse Analytics

Every request to Synapse passes through more than one permission system. Understanding which layer answers which question avoids both gaps and over-granting.

Layer	What it controls	Where it is managed	Typical holders
Azure RBAC	Creating and managing the workspace, SQL pools, Spark pools and integration runtimes; networking settings; assigning Synapse RBAC roles (Azure Owners)	Azure portal, Access control (IAM)	Platform administrators group with Contributor on the workspace
Synapse RBAC	Publishing and running code, artifacts, Spark jobs, pipelines, linked services, credentials and managed private endpoints	Synapse Studio, Manage, Access control	Administrators, contributors, compute operators, credential users
SQL permissions	Data access inside dedicated and serverless SQL pools (logins, users, database roles)	T-SQL in each database	Microsoft Entra admin group, analysts with `db_datareader`, engineers with `db_datawriter`
Storage RBAC	Reading and writing data in the primary ADLS Gen2 account and other lakes	Azure RBAC on the storage account or container	Workspace managed identity, developer groups

Microsoft's access control walkthrough builds this around five Microsoft Entra security groups: Synapse Administrators, Synapse Contributors, Synapse Compute Operators, Synapse Credential Users and SQL Admins. Groups must be of type Security, as Microsoft 365 groups are not supported for Azure SQL. Assign roles to these groups, never to individuals, so joiners and leavers are handled in one place.

SQL authentication

A workspace has two SQL administrator accounts: the original SQL administrator login (SQL authentication) and the Microsoft Entra administrator. The workspace creator is assigned as the SQL Active Directory Admin automatically, and only one user or group can hold that role at a time. Set it to the SQL Admins security group so membership changes in Entra ID take effect without touching the workspace. The Microsoft Entra admin controls access to dedicated SQL pools, while Synapse RBAC roles such as Synapse Administrator and Synapse SQL Administrator control access to serverless pools; Synapse Administrators receive db_owner on serverless pools by default.

Select Use only Microsoft Entra authentication at creation, or turn it on later once a Microsoft Entra admin exists. The SQL administrator login is still created but disabled. Entra authentication supports MFA through Entra Universal with MFA in tools such as SSMS, and token authentication for applications. An Azure Owner or Contributor can re-enable local authentication, so monitor that setting.

Admin roles and privileged access

Synapse RBAC has eleven documented built-in roles. Anyone holding any Synapse RBAC role at any scope automatically holds Synapse User at workspace scope. The roles below carry the most power and deserve privileged access treatment.

Role	Key permissions	Why it is sensitive
Synapse Administrator	Full access to SQL, Data Explorer and Spark pools and integration runtimes; all published artifacts; can use stored secrets; assigns and revokes Synapse RBAC roles	Complete control of the workspace and its credentials
Synapse Credential User	Uses secrets in credentials and linked services at run and configuration time; required to run pipelines with the workspace system identity	Reaches every data source behind those credentials
Synapse Linked Data Manager	Creates and manages managed private endpoints, linked services and credentials	Can open new network paths and define new connections
Synapse Apache Spark Administrator, Synapse SQL Administrator	Full access to their pool type, artifacts, linked services and credentials	Broad data access within the pool type
Synapse Contributor	Reads and writes published artifacts including pipelines and linked services; Spark and integration runtime compute	Can change what pipelines do once someone with credential rights runs them
Azure Owner or Contributor on the workspace	Creates pools and runtimes, changes networking; Owners can assign Synapse RBAC roles	Control plane power over the whole workspace

Separate duties: Keep Synapse Contributor (who writes pipelines) apart from Synapse Credential User (who runs them with secrets) for production workspaces, so no single developer can both change and execute code against sensitive sources.
Scope narrowly: Synapse Credential User and Synapse Administrator can be assigned at linked service or credential scope, and Synapse Compute Operator at Spark pool or integration runtime scope. Use these narrower scopes where a team needs only one connection or one pool.
Make admin access eligible: Put the Synapse Administrators and Azure Contributor groups behind just-in-time activation, as described in the Azure RBAC and Service Principals Guide.
Review assignments: Synapse RBAC role assignments can be made even when the subscription is disabled, and they are separate from Azure RBAC, so review both lists each quarter.

Integrations, API tokens and service accounts

Linked services are where Synapse stores the means to reach other systems, which makes them the most important non-human identity surface in the workspace.

Workspace managed identity: Synapse uses the workspace managed identity, named after the workspace, to run pipelines and system tasks. Grant it Storage Blob Data Contributor on the default container of the primary ADLS Gen2 account, scoped to the container rather than the whole account, and grant it only the roles each target needs. See the Azure Managed Identities Security Guide.
Key Vault references: Store passwords, keys and connection strings in Azure Key Vault and reference them from linked services with an AzureKeyVaultSecret reference. Grant the managed identity Key Vault Secrets User (or Get and List secret permissions under an access policy). Leave secretVersion empty so rotation in Key Vault takes effect without editing the linked service; pin a version only when you need to. See the Azure Key Vault Security Guide.
Connection strings: For connectors that use connection strings, store the whole string or just its secret part in Key Vault. Prefer managed identity authentication to the target wherever the connector offers it, so there is no secret to store.
Self-hosted integration runtime: The runtime host reaches on-premises sources with its own credentials. Harden the host, restrict who can register nodes, and keep its keys in Key Vault.
Applications querying SQL pools: Applications should connect with Microsoft Entra token authentication using a managed identity or service principal, created as contained database users with only the database roles they need, rather than shared SQL logins.
Git integration: Synapse Studio supports Git mode. Protect the main branch, require reviews for changes to linked services and pipelines, and keep secrets out of the repository by using Key Vault references.
Downstream reporting: Power BI datasets that read from Synapse carry their own credentials and sharing model, covered in the Power BI Security Guide.

Network isolation and data exfiltration protection

Synapse offers a managed workspace virtual network that Azure Synapse manages for you. Data integration and Spark resources run inside it, each Spark cluster in its own subnet. Dedicated and serverless SQL pools are multitenant and run outside it, connected to the workspace through Azure Private Link that is created automatically with the managed virtual network.

Setting	When it can be set	Effect
Enable managed virtual network	Creation only (Networking tab)	Places Spark and integration runtimes in a Synapse-managed network; enables managed private endpoints
Allow outbound data traffic only to approved targets (data exfiltration protection)	Creation only	Outbound traffic from the managed network goes only through managed private endpoints, and only to resources in approved Microsoft Entra tenants
Public network access	Creation or later (managed virtual network workspaces only)	When disabled, dedicated and serverless SQL pools and development endpoints are reachable only through private endpoints
Workspace IP firewall rules	Creation or later (Security, Firewalls)	Server-level rules for all public endpoints, up to 128 rules
Allow Azure services and resources to access this workspace	Creation or later	Allows connections from all Azure sources, including other customers' subscriptions
Minimal TLS version	REST API	TLS 1.2 is the minimum; after 31 March 2025 it cannot be set lower

With data exfiltration protection on, Synapse SQL can still read any authorised storage account with OPENROWSET or external tables, but egress to external storage through CREATE EXTERNAL TABLE AS SELECT or COPY INTO with ERRORFILE is blocked until you create a managed private endpoint for the target account. Managed private endpoints to resources in unapproved tenants are blocked. Two limits matter for design: protection controls egress only, not ingress, and pipelines in a protected workspace should use the managed virtual network integration runtime rather than the public Azure integration runtime. Microsoft notes that some artifacts may still reference the public Azure integration runtime and recommends reviewing them. If a workload genuinely needs public egress, Microsoft advises using a separate workspace without protection rather than mixing the two.

Choosing the right configuration:

Situation	Configuration
Regulated or confidential data, defined set of sources	Managed virtual network, data exfiltration protection, public network access disabled, private endpoints for clients
Internal analytics with some public sources	Managed virtual network without exfiltration protection, managed private endpoints for internal stores, tight firewall rules
Small team, proof of concept	Firewall rules limited to known addresses, Entra-only authentication, no "Allow Azure services"; create production in a new, isolated workspace

Firewall changes made in the portal use POST operations that Azure Policy cannot block, and Microsoft states that no policy is currently available to prevent changes to workspace networking settings. Compensate with activity log alerts. For broader network design see the Azure Virtual Network Security Guide, and for egress risk in general the Data Exfiltration Guide.

Logging and detection

Synapse resource logs are not collected until you create a diagnostic setting. Send them to a Log Analytics workspace (or storage and Event Hubs for a SIEM), and enforce the setting with Azure Policy. See the Azure Monitor, Activity Log and Diagnostic Settings Guide.

Log category (Microsoft.Synapse/workspaces)	Use it to detect
`SynapseRbacOperations`	Synapse role assignments and removals, especially Administrator and Credential User grants
`SQLSecurityAuditEvents`	SQL logins, permission changes and unusual queries against sensitive tables
`BuiltinSqlReqsEnded`	Serverless SQL request volume and data processed, useful for spotting bulk reads
`GatewayApiRequests`	Workspace API calls by caller
`IntegrationPipelineRuns`, `IntegrationActivityRuns`, `IntegrationTriggerRuns`	Pipelines run at unusual times, new triggers and copy activities to new sinks
`BigDataPoolAppsEnded` (bigDataPools)	Spark applications submitted outside normal patterns

Workspace categories land in the AzureDiagnostics table. Pair them with the Azure Activity Log for control plane changes: firewall rules, public network access, managed private endpoint approvals and changes to Entra-only authentication. Metrics that show the controls are working:

Number of individual users (not groups) holding Synapse RBAC roles (target zero).
Number of principals holding Synapse Administrator or Synapse Credential User at workspace scope.
Percentage of linked services using managed identity or Key Vault references rather than inline secrets.
Production workspaces with data exfiltration protection and public network access disabled.
Time from an unapproved firewall or role change to alert and review.

Hardening baseline

Design before creation: Decide managed virtual network, data exfiltration protection, approved Entra tenants and Entra-only authentication before you create the workspace, because the network choices are permanent.
Create the groups: Create the five security groups and grant storage access to the administrator, contributor and compute operator groups.
Create the workspace: Enable the managed virtual network, data exfiltration protection where data is sensitive, and Use only Microsoft Entra authentication. Set the SQL Admins group as Microsoft Entra admin.
Assign roles: Assign Synapse RBAC roles to groups, give the administrators group Azure Contributor on the workspace, and grant the managed identity Storage Blob Data Contributor on the default container only.
Close public access: Disable public network access and give clients private endpoints, or restrict firewall rules to known ranges and leave "Allow Azure services" off.
Move secrets: Point every linked service at Key Vault or managed identity authentication, then remove inline secrets.
Turn on logging: Create diagnostic settings for all workspace categories and alert on role, firewall and authentication changes.
Test and roll back: Pilot changes in a non-production workspace first. Role and firewall changes can be reversed; network isolation cannot, so a rollback for it means building a new workspace and moving artifacts through Git.

Planning a move to Microsoft Fabric

Microsoft publishes migration guidance for moving Synapse dedicated SQL pools to Fabric Data Warehouse (including a Migration Assistant), Synapse Spark to Fabric Data Engineering, and Synapse Data Explorer to Fabric Eventhouse (in preview at the time of writing). The Spark migration overview places security in its own phase covering roles, connections, governance, verification and cutover. Treat migration as a fresh security design rather than a lift and shift:

Inventory first: List every linked service, credential, managed private endpoint, approved tenant and Synapse RBAC assignment before moving anything. Each needs an explicit equivalent in Fabric.
Re-create access deliberately: Fabric uses its own workspace roles and item permissions, so map Synapse groups to Fabric roles on least privilege rather than copying broad grants.
Re-establish network controls: Confirm the Fabric private link and outbound controls you need before moving data that was protected by data exfiltration protection.
Retire what you leave behind: Once a workload has moved, remove its Synapse linked services, rotate the secrets they used and delete unused managed private endpoints.

Fabric's controls are covered in the Microsoft Fabric Security guide.

Common misconfigurations

Creating the workspace before deciding on isolation: A workspace created without a managed virtual network cannot gain one later. Decide in design review.
Credential User granted broadly: Giving every developer Synapse Credential User at workspace scope lets anyone run any pipeline with every secret. Grant it to a small group, or at linked service scope.
Roles assigned to individuals: Direct assignments survive role changes and are hard to review. Use the security groups.
SQL administrator login left enabled: A password based login with full rights bypasses Entra controls such as MFA and Conditional Access. Turn on Entra-only authentication.
"Allow Azure services" left on: This rule admits connections from any Azure subscription. Use private endpoints or specific firewall ranges instead.
Diagnostic settings missing: Without them, role changes and SQL audit events are not retained. Enforce them with Azure Policy.

Framework mapping

Control area	NIST SP 800-53 Rev 5	NIST CSF 2.0	ISO/IEC 27001:2022 Annex A
Synapse RBAC, SQL roles and separation of duties	AC-3, AC-6	PR.AA-05	A.5.15 Access control, A.8.2 Privileged access rights
Entra-only authentication and MFA	IA-2	PR.AA-05	A.8.5 Secure authentication
Linked service secrets in Key Vault	IA-5	PR.AA-05	A.5.17 Authentication information
Managed virtual network, exfiltration protection, firewall	SC-7	PR.IR-01	A.8.20 Networks security, A.8.22 Segregation of networks
Diagnostic logs and SQL auditing	AU-2, AU-6, SI-4	DE.CM-09	A.8.15 Logging, A.8.16 Monitoring activities

Practitioner checklist

Decide managed virtual network and data exfiltration protection in design review, before workspace creation.
Create the five security groups and assign every Synapse RBAC role to a group, not a user.
Set a security group as Microsoft Entra admin and turn on Microsoft Entra-only authentication.
Limit Synapse Administrator and Synapse Credential User to small groups, using narrower scopes where possible.
Grant the workspace managed identity only container scoped storage roles and the roles each target needs.
Move every linked service secret to Key Vault or managed identity authentication.
Disable public network access or restrict firewall rules, and leave "Allow Azure services" off.
Maintain the approved Microsoft Entra tenant list and review managed private endpoint approvals.
Collect all workspace log categories and alert on role, firewall and authentication changes.
Before any Fabric migration, inventory credentials, endpoints and roles, and rotate secrets after cutover.

Azure Synapse Analytics Security: Lock Down Workspaces, Credentials and Data Egress