Candidate fix for #59, data exfiltration via AzureML

[TonyWildish-BH]

One candidate fix for the AzureML data breach is Conditional Access Policies. This works by blocking AzureML traffic from crossing the SDE firewall, which has a static IP address already allocated to it.

The plan below comes from a chat with an LLM that knows about these things. We won't execute this plan until we have feedback from MS on their take on things.

Acceptance Criteria

1. Egress IP capture

• 1.1 Identify the existing fixed public IP used by the SDE’s Azure Firewall as a Terraform output for use in the next steps.

2. Conditional Access policies

• 2.1 Create an Entra ID named location “SDE-Egress” that contains the IP from 1.1.
• 2.2 Implement CA policy SDE-inside-block-external-AML with:
  • Cloud apps = “Azure Machine Learning”, “Azure Storage”
  • Include = All users
  • Locations = only “SDE-Egress”
  • Grant = Block access
  • Exclude = Group “SDE-BreakGlass”.
• 2.3 Implement CA policy SDE-outside-block-internal-AML with:
  • Cloud apps = “Azure Machine Learning”, “Azure Storage”
  • Include = All users
  • Locations = all trusted locations except “SDE-Egress”
  • Grant = Block access
  (No checkbox needed for note: Access to SDE AML workspaces is already blocked externally because public network access is disabled.)
• 2.4 Create a PIM-enabled Entra ID group “SDE-BreakGlass”; require approval, set time-bound activation, and ensure auditing is enabled.
• 2.5 Store both CA policies as JSON and deploy them.

3. Azure Policy guard-rail

• 3.1 Author policy definition amlPublicNetworkDisabled that denies creation or update when properties.publicNetworkAccess == "Enabled".
• 3.2 Assign the policy at the SDE subscription level and add it to the TRE policy set.
• 3.3 Verify policy compliance: 100 % of existing SDE AML workspaces report compliant status.

4. Validation / automated tests

• 4.1 From an SDE VM, run az ml workspace list --subscription <external-sub-id> and confirm it returns HTTP 403.
• 4.2 From a non-SDE host, attempt to reach the storage endpoint of an SDE AML workspace and confirm the connection fails.

5. Documentation

• 5.1 Update the operator runbook:
  • Procedure to rotate the firewall IP and update the named location.
  • Steps to activate BreakGlass access via PIM.
• 5.2 Update the user guide to explain that ML workspaces outside the SDE are intentionally inaccessible from inside the SDE.

6. Break-glass drill

• 6.1 Conduct a tabletop exercise: an on-call engineer activates the PIM role, accesses an external ML workspace from inside the SDE, then relinquishes the role.
• 6.2 Capture audit logs confirming both activation and de-activation events.

7. Post-deployment monitoring

• 7.1 Create an Azure Monitor alert: any failure of the CA policies “SDE-inside-block-external-AML” or “SDE-outside-block-internal-AML” triggers a Severity 2 alert to the SecOps mailbox.

[TonyWildish-BH]

I've been working this through, but there's a snag: Using Conditional Access Policies requires disabling Security Defaults, the two features are mutually exclusive. If Security Defaults are turned on in a tenant, Azure AD blocks every attempt to create, enable or update a CA policy and returns an error.

So we must disable Security Defaults before enabling a Conditional Access policy. However, that means we need to re-create the protection that Security Defaults gives us.

How to fix it

Disable security defaults, then create the CA policy

Portal

1. Azure portal → Azure Active Directory → Properties.
2. At the bottom, click “Manage security defaults”.
3. Set the toggle to No → Save.

Graph / CLI

TENANT=$(az account show --query tenantId -o tsv)

az rest \
  --method PATCH \
  --url https://graph.microsoft.com/v1.0/organization/$TENANT \
  --headers Content-Type=application/json \
  --body '{"securityDefaultsEnabled": false}'

After the change we can create Conditional Access Policies.

What changes when you turn security defaults off?

Security defaults automatically enforce a basic security baseline for every user in the tenant:

• Require MFA for all admins and privileged roles
• Block legacy (basic) authentication protocols
• Protect Azure portal, Azure PowerShell, CLI, etc. with MFA
• Force registration of MFA/authentication methods within 14 days

The moment you disable it, those protections disappear until you put equivalent Conditional Access policies in place. Microsoft’s recommendation is to create at least the following CA policies immediately:

1. Require MFA for all users, exclude emergency break-glass accounts.
2. Require MFA for administrative roles on every sign-in.
3. Block legacy authentication.
4. (Optional) Require compliant or hybrid-joined devices, location-based rules, etc.

Can you turn security defaults back on afterwards?

Yes, but only if no Conditional Access policies are enabled in the tenant.

• To re-enable security defaults you must disable or delete every CA policy first; otherwise Azure AD returns the mirror error: “Disable all Conditional Access policies before enabling Security defaults.”
• When you re-enable security defaults, none of your CA policies are evaluated.