This is a bit of a niche bug, but has come up in our production instance.

We have users who have access to the SDE to carry out research, including the use of AzureML.

Some of these users also have access to a resource group in a different subscription in the same tenancy, where they can deploy resources, including AzureML.

When they visit ml.azure.com from inside the SDE, they can see their external ML workspaces. They can upload data from the SDE to Jupyter notebooks in that external workspace. They can then go outside the SDE, connect to the same notebook, and download the data, bypassing the airlock completely.

Steps to reproduce

1. Create a user who has SDE Workspace Admin role for a workspace.
2. Create a resource group for them outside the SDE, grant them Contributor access to it.

Then, as that user:
3. Create an AzureML workspace and a Jupyter notebook in that external resource group.
4. Create a VM in the SDE workspace.
5. From the VM, launch a browser and go to ml.azure.com.
6. Navigate to the AzureML instance you created in step 3, create a Jupyter notebook.
7. Upload a file from the SDE VM to the notebook storage. This is the point where the breach occurs.
8. From outside the SDE, open a browser, go to ml.azure.com.
9. Find the Jupyter notebook, download the file.

Azure TRE release version (e.g. v0.14.0 or main):
v0.21.0

Deployed Azure TRE components - click the (i) in the UI:
UI Version: 0.7.0
API Version: 0.21.1

One obvious fix is to have the SDE in a unique tenancy, not used for other purposes, but that's not necessarily convenient (it isn't for us).

Another possibility would seem to be the use of Conditional Access Policies, barring AzureML traffic from crossing the SDE boundary. I'm no expert here, but it seems from googling that CAPs can use the SDE firewall public IP address to do that?

Any other options?