Microsoft
MicrosoftHi luke-MSFT & swoeng
We are already using Synapse for over a year now and we switched DEP on because Microsoft docs imply that in a corporate setup with high security requirements it makes sense. However, I still do not fully understand the purpose / the thread scenarios that DEP offers protection for (that cannot be achieved another way) - and I have the impression, that even Microsoft employees do not understand the feature (and its limitations) entirely either...
Also, as mentioned above DEP comes at great costs/limitations that we are not willing to accept any longer.
I have some questions:
A Microsoft Cloud Solution Architect once explained to me:
"The managed VNet feature makes it easier for the customer to protect against outbound data exfiltration. With managed VNet enabled no service (Key Vault, Storage Account, SQL DB) can be contacted without a managed private endpoint"
However your article states:
"When using the Azure Integration Runtime with DEP enabled, Linked Service connection (that is to say connections to other services) must occur through managed private endpoints."
So, what is it? Does managed VNet or DEP enforce having traffic go through managed private endpoints?
As far as I understand correctly, the most prominent thread scenario DEP protects against is described here: https://learn.microsoft.com/en-us/azure/synapse-analytics/security/workspace-data-exfiltration-protection#sample-workspace-with-data-exfiltration-protection-enabled
However, I was wondering: creating a managed private endpoint is a task that required specific admin rights as you pointed out above (https://learn.microsoft.com/en-us/azure/synapse-analytics/security/synapse-workspace-synapse-rbac-roles#synapse-rbac-actions-and-the-roles-that-permit-them). So, this thread scenario already assumes that an admin has gone rogue. If this admin also had the contributor-role on the Synapse Workspace he would be able to simply add the hostile tenant to the approved list and then create the managed private endpoint, correct? If it was not the same admin but a second admin who has the contributor-role it would require those two admins to go rogue to carry out this thread scenario.
What if DEP was disabled and no human admin had the rights to create linked services and managed private endpoints themselves? Instead there is a DevOps pipeline that creates those artifacts via Infrastructure-as-Code; but before it runs, it requires the approval of two (or more) admins. Also, additional Azure Alerts could be set up that fire when a new managed private endpoint is created to inform some security officer and review the changes, right? Wouldn't this provide the same level of protection against the mentioned thread scenario above?
https://learn.microsoft.com/en-us/azure/synapse-analytics/guidance/security-white-paper-network-security#data-exfiltration-protection
“[DEP] protects all egress traffic going out from Azure Synapse from all services, including dedicated SQL pools, serverless SQL pools, Apache spark pools, and pipelines”
To my understanding DEP achieves this egress protection by simply forbidding all outbound traffic (except for the one that runs through a managed private endpoint).
What if we need to connect to OnPrem data sources (like OnPrem Kafka) from Synapse Spark Notebooks directly or to Public Internet Rest APIs? DEP will prevent this traffic. A self-hosted Integration Runtime is no option here since Synapse Spark Notebooks do not run on an integration runtime.
I was wondering: If we'd like to have fine-grained control, what outbound traffic should be allowed and what should be blocked, wouldn't a https://learn.microsoft.com/en-us/azure/firewall/overview or a 3rd Party https://learn.microsoft.com/en-us/azure/architecture/reference-architectures/dmz/nva-ha be an adequate or even more powerful alternative to DEP? If so, why is this not found in any of Microsofts Docs?
