Stop fighting Azure security alerts. This guide breaks down how we built an autonomous remediation system for public blobs, NSG gaps, and private endpoints, going from quick scripts to unshakeable policy-driven guardrails.

That 3 AM Alert: How We Built an Autonomous Azure Security Janitor

I’ll never forget the PagerDuty alert at 3:17 AM. “CRITICAL: Publicly Accessible Blob Storage Detected.” My heart sank. It was a dev environment, stg-dev-customer-uploads-temp, but an automated scanner saw files named customer_list_export.csv and went into DEFCON 1. It turned out to be dummy data, but for two hours, half the engineering leadership and the entire compliance team were on a call trying to figure out if we’d just leaked our entire user base. All because a developer, under pressure for a demo, needed to share a file quickly and clicked “Allow public access.” We spent the next week building a system to make sure that call, that panic, could never, ever happen again.

So, Why Does This Keep Happening?

Look, let’s be real. No developer wakes up in the morning wanting to expose company data. The root cause isn’t malice; it’s the path of least resistance. The Azure portal is a massive, powerful tool, but it also makes it incredibly easy to do insecure things if you don’t know any better. Your team is under pressure to ship features, not become IAM policy experts. They need to get a proof-of-concept working, connect a web app to a database, or open a port for a quick test. Without clear, automated guardrails, convenience will win over security nine times out of ten. This isn’t a “people problem” to be solved with more training; it’s a systems problem that needs a systems solution.

The Fixes: From a Band-Aid to Body Armor

We attacked this problem on three fronts. You can start with the first one today and work your way up. Each level provides more protection but also requires a bit more investment.

1. The Quick Fix: The Reactive Janitor

This is your emergency stop-gap. It doesn’t prevent the problem, but it cleans up the mess within minutes, automatically. We built this with an Azure Logic App that listens for alerts from Microsoft Defender for Cloud.

Here’s the high-level flow:

• Trigger: Microsoft Defender for Cloud alert is created (e.g., “Storage accounts should restrict network access” or “NSG rule allows internet traffic to a virtual machine”).
• Parse: The Logic App gets the alert payload and extracts the ARM ID of the offending resource.
• Remediate: It uses a managed identity with the right permissions to call the Azure API and fix the issue. For a public blob, it sets the `publicNetworkAccess` property to `Disabled`. For an open NSG port, it might remove the specific “allow” rule.
• Notify: Finally, it posts a message to a security channel in Teams: “AUTOREMEDIATION: Disabled public access on stg-dev-customer-uploads-temp. A private endpoint is required for access. Ticket #TICKET-123 created.”

Pro Tip: This is a fantastic “first step” because it immediately reduces your mean time to remediation (MTTR) from hours to minutes. However, remember it’s reactive. The misconfiguration *did* exist, even if only for a short time.

2. The Permanent Fix: The Proactive Gatekeeper

This is where you stop cleaning up messes and start preventing them. Azure Policy is the real hero here. Instead of waiting for an alert, Policy evaluates any resource creation or update against your rules and can flat-out deny it if it’s non-compliant.

We use a combination of Policy effects depending on the resource and severity:

For example, here’s a simplified version of the policy definition we use to block public storage accounts. When a developer tries to deploy this via Terraform, the Azure API itself rejects the request with a clear error.

{
  "mode": "All",
  "policyRule": {
    "if": {
      "allOf": [
        {
          "field": "type",
          "equals": "Microsoft.Storage/storageAccounts"
        },
        {
          "field": "Microsoft.Storage/storageAccounts/publicNetworkAccess",
          "notEquals": "Disabled"
        }
      ]
    },
    "then": {
      "effect": "deny"
    }
  },
  "parameters": {}
}

3. The ‘Nuclear’ Option: The Pre-Commit Sheriff

The final frontier is shifting this logic all the way left, before the code even gets to Azure. We integrated Infrastructure-as-Code (IaC) scanning directly into our CI/CD pipelines. A pull request to our `main` branch can’t even be merged if it contains insecure configurations.

We use tools like Checkov or Terrascan that have built-in libraries of security rules. Here’s what a simple GitHub Actions step looks like:

- name: Run Terrascan IaC Scan
  id: terrascan
  uses: accurics/terrascan-action@v1.4.0
  with:
    iac_type: 'terraform'
    iac_version: 'v12'
    policy_type: 'azure'
    # The --non-recursive flag is important for monorepos
    only_warn: false # This makes the step fail the build on violations

If a developer tries to commit Terraform code with an NSG rule like `source_address_prefix = “0.0.0.0/0″` for port 3389, the pipeline breaks. The PR is blocked. The feedback is immediate, right inside their development workflow.

Warning: Be prepared for some friction here. This approach can feel “heavy-handed” to developers initially. You absolutely MUST provide clear documentation, secure templates, and good error messages. The goal isn’t to be a blocker; it’s to make the secure path the easiest path.

Starting with a reactive “janitor” bought us time and stopped the bleeding. Layering on Azure Policy provided the real, preventative guardrails. And finally, pushing security into the CI pipeline made it part of our development DNA. You don’t have to boil the ocean, but you do have to start. Trust me, it’s better than getting that 3 AM call.

Darian Vance

Lead Cloud Architect & DevOps Strategist

With over 12 years in system architecture and automation, Darian specializes in simplifying complex cloud infrastructures. An advocate for open-source solutions, he founded TechResolve to provide engineers with actionable, battle-tested troubleshooting guides and robust software alternatives.

🤖 Frequently Asked Questions