DEV Community: david

NIS2 Article 21 in Azure: Implementing Network Security Controls with Terraform

david — Thu, 21 May 2026 22:00:00 +0000

NIS2 Article 21 in Azure: Implementing Network Security Controls with Terraform

Tags: terraform, azure, security, devops

Canonical URL: https://woitzik.dev/blog/nis2-article-21-azure-terraform

Most NIS2 content is written by lawyers for lawyers. This article maps Article 21 network security requirements to concrete Azure resources — with Terraform code, not legal theory.

Disclaimer: This covers technical network infrastructure controls relevant to NIS2 Article 21. Full compliance requires organizational measures beyond infrastructure code. Nothing here constitutes legal advice.

What NIS2 Article 21 Actually Requires (For Engineers)

Four concrete network security areas:

Network Segmentation — isolate systems by criticality
Access Control — Default-Deny at network and identity layer
Minimize Attack Surface — eliminate unnecessary public endpoints
Auditability — traceable, version-controlled infrastructure changes

Here's how each maps to Azure Terraform resources.

Control 1: Network Segmentation via Hub & Spoke

Spoke-to-Spoke traffic blocked by default — all cross-workload communication routes through the Hub:

resource "azurerm_virtual_network_peering" "hub_to_spoke1" {
  name                      = "peer-hub-to-spoke1"
  virtual_network_name      = azurerm_virtual_network.hub.name
  remote_virtual_network_id = azurerm_virtual_network.spoke1.id
  allow_forwarded_traffic   = true
}

Spokes only peer with the Hub — never with each other. Cross-Spoke traffic must be explicitly routed through the Firewall.

Control 2: Default-Deny NSG Baseline

security_rule {
  name                       = "Allow-VNet-Inbound"
  priority                   = 100
  access                     = "Allow"
  source_address_prefix      = "VirtualNetwork"
  destination_address_prefix = "VirtualNetwork"
}

security_rule {
  name                       = "Deny-Internet-Inbound"
  priority                   = 4096
  access                     = "Deny"
  source_address_prefix      = "Internet"
  destination_address_prefix = "*"
}

Priority gap (100 → 4096) leaves room for application rules without restructuring the baseline.

Control 3: Egress Control via Forced Tunneling

All outbound Spoke traffic through Azure Firewall — logged, inspectable, FQDN-controlled:

route {
  name                   = "route-to-firewall"
  address_prefix         = "0.0.0.0/0"
  next_hop_type          = "VirtualAppliance"
  next_hop_in_ip_address = azurerm_firewall.fw.ip_configuration[0].private_ip_address
}

# Critical — without these, Windows VMs lose activation
route {
  name           = "bypass-azure-kms"
  address_prefix = "23.102.135.246/32"
  next_hop_type  = "Internet"
}

The Firewall log is your audit trail for NIS2 Article 21(2)(b) — monitoring and incident detection.

Control 4: Zero Public PaaS Endpoints

resource "azurerm_key_vault" "kv" {
  public_network_access_enabled = false

  network_acls {
    default_action = "Deny"
    bypass         = "AzureServices"
  }
}

An external scanner gets no TCP connection — the endpoint doesn't resolve to a public IP. Directly satisfies NIS2 Article 21(2)(h).

Control 5: No Static Credentials

Managed Identity + scoped RBAC — no connection strings, no access keys:

resource "azurerm_role_assignment" "app_kv_secrets" {
  scope                = azurerm_key_vault.kv.id
  role_definition_name = "Key Vault Secrets User"
  principal_id         = azurerm_linux_function_app.app.identity[0].principal_id
}

When the resource is deleted, identity and permissions are automatically destroyed.

Control 6: Auditability via IaC

Every change is a Git commit. terraform plan is an audit artifact. No ClickOps, no undocumented Portal changes.

What This Covers — and What It Doesn't

This addresses technical network controls only. Full NIS2 compliance also requires incident response procedures, supply chain risk management, business continuity measures, and organizational governance.

Infrastructure code is the foundation. Compliance is the full building.

Full article with complete code for all six controls on my blog.

👉 Full article on woitzik.dev

Zero-Trust RAG: Defeating the Shared Private Link Deadlock in Azure Terraform

david — Wed, 20 May 2026 22:00:00 +0000

Your Terraform pipeline is green. The deployment completes without errors. You grab a coffee.

Ten minutes later, you test your new Enterprise RAG application. It throws a 403 Forbidden. You open the Azure Portal, check the OpenAI Networking tab, and there it is: your Shared Private Link from AI Search is sitting in Pending.

Nobody told Terraform to approve it. Nobody told you it even needed approving.

This is the CI/CD killer of Azure AI infrastructure.

Why It Happens

AI Search must call OpenAI to vectorize data. The azurerm provider can successfully request this Shared Private Link — but it cannot approve its own request. The target resource (OpenAI) must explicitly accept the inbound connection. The standard provider has no method for this. Pipeline deadlocked. Someone has to click "Approve" in the Portal manually. ClickOps in 2026.

The AzAPI State Machine Fix

We bypass the azurerm provider entirely and talk directly to the Azure Resource Manager REST API using the azapi provider.

Because Azure generates a random GUID for the incoming connection, we can't hardcode the ID — we read it at runtime:

data "azapi_resource_list" "pe_connections" {
  type                   = "Microsoft.CognitiveServices/accounts/privateEndpointConnections@2023-05-01"
  parent_id              = azurerm_cognitive_account.openai.id
  response_export_values = ["value"]

  depends_on = [azurerm_search_shared_private_link_service.openai_link]
}

The depends_on is critical — without it, Terraform queries the connection list before the link is even requested, returns empty, and the approval silently fails.

Then we filter for the Pending connection and approve it:

resource "azapi_update_resource" "approve_shared_link" {
  type = "Microsoft.CognitiveServices/accounts/privateEndpointConnections@2023-05-01"

  resource_id = try(
    [for conn in jsondecode(data.azapi_resource_list.pe_connections.output).value :
      conn.id
      if conn.properties.privateLinkServiceConnectionState.status == "Pending"
    ][0],
    ""
  )

  body = jsonencode({
    properties = {
      privateLinkServiceConnectionState = {
        status      = "Approved"
        description = "Approved via Terraform AzAPI Pipeline"
      }
    }
  })
}

The try() wrapper is not optional. On terraform destroy, the Shared Private Link is deleted before this resource is evaluated. Without try(), indexing [0] on an empty array crashes the destroy run and leaves orphaned resources in Azure.

After terraform apply, the link goes from Pending to Approved in under 30 seconds. No Portal access required.

Identity Chaining — Kill the API Keys

Auto-approving the link lets AI Search reach OpenAI. But static API keys will fail your compliance audit. Keys leak. Keys get committed to Git.

Disable local auth and use a System Managed Identity instead:

resource "azurerm_search_service" "search" {
  name                         = var.search_service_name
  sku                          = "standard"
  public_network_access_enabled = false
  local_authentication_enabled  = false

  identity {
    type = "SystemAssigned"
  }
}

resource "azurerm_role_assignment" "search_to_openai" {
  scope                = azurerm_cognitive_account.openai.id
  role_definition_name = "Cognitive Services OpenAI User"
  principal_id         = azurerm_search_service.search.identity[0].principal_id
}

Zero credential management. When the AI Search instance is deleted, its identity and permissions are destroyed automatically.

Don't Forget Private DNS

If your-instance.openai.azure.com still resolves to a public IP, the Azure Firewall drops the traffic and you get another opaque 403. Both services need their DNS zones linked to the VNet:

resource "azurerm_private_dns_zone" "openai_dns" {
  name                = "privatelink.openai.azure.com"
  resource_group_name = var.resource_group_name
}

resource "azurerm_private_dns_zone_virtual_network_link" "openai_vnet_link" {
  name                  = "link-openai-vnet"
  resource_group_name   = var.resource_group_name
  private_dns_zone_name = azurerm_private_dns_zone.openai_dns.name
  virtual_network_id    = azurerm_virtual_network.vnet.id
  registration_enabled  = false
}

registration_enabled = false — always. Automatic registration conflicts with centralized Hub & Spoke DNS management.

The free baseline (AzAPI auto-approval + basic networking) is on GitHub. The full article with complete VNet injection, Private DNS automation, and RBAC Identity Chaining is on my blog.

👉 Full article on woitzik.dev
👉 Free GitHub repo

Surviving Azure Policies: Zero-Trust Hub & Spoke with Terraform

david — Mon, 18 May 2026 22:00:00 +0000

Your Terraform pipeline is green. The deployment completes. You grab a coffee.

Ten minutes later, Azure Policy has silently rewritten three of your resources. You run terraform plan. It detects drift. It tries to revert. Policy blocks the revert with a cryptic permission error. Your pipeline is now permanently broken — and nobody touched the code.

This is Tuesday in an enterprise Azure tenant.

The DINE Death Loop

DeployIfNotExists policies run continuously in the background. They inject tags like CreatedByPolicy=True or hidden-title into your resources for compliance tracking.

Terraform sees these injected tags as drift. It plans to delete them. Azure Policy blocks the deletion. Your pipeline fails. This repeats on every run. Forever.

The fix is surgical — tell Terraform to ignore exactly these tags and nothing else:

resource "azurerm_private_dns_zone" "enterprise_zones" {
  for_each            = toset(var.private_dns_zones)
  name                = each.key
  resource_group_name = azurerm_resource_group.rg.name

  lifecycle {
    ignore_changes = [
      tags["hidden-title"],
      tags["CreatedByPolicy"]
    ]
  }
}

Terraform now maintains the infrastructure. The compliance scanner gets its metadata. Nobody fights. No pipeline failures.

Zero-Trust NSG Baseline

A default Azure VNet allows unrestricted lateral movement and outbound internet access. For any ISO 27001 or KRITIS audit, this is an immediate finding.

The fix: an NSG bound to Spoke subnets at creation — not as a follow-up ticket:

resource "azurerm_network_security_group" "zero_trust" {
  name                = "nsg-zero-trust-${var.environment}"
  location            = azurerm_resource_group.rg.location
  resource_group_name = azurerm_resource_group.rg.name

  security_rule {
    name                       = "Allow-VNet-Inbound"
    priority                   = 100
    direction                  = "Inbound"
    access                     = "Allow"
    protocol                   = "*"
    source_address_prefix      = "VirtualNetwork"
    destination_address_prefix = "VirtualNetwork"
    source_port_range          = "*"
    destination_port_range     = "*"
  }

  security_rule {
    name                       = "Deny-Internet-Inbound"
    priority                   = 4096
    direction                  = "Inbound"
    access                     = "Deny"
    protocol                   = "*"
    source_address_prefix      = "Internet"
    destination_address_prefix = "*"
    source_port_range          = "*"
    destination_port_range     = "*"
  }
}

# Critical: bind it immediately — an unbound NSG enforces nothing
resource "azurerm_subnet_network_security_group_association" "spoke1_nsg" {
  subnet_id                 = azurerm_subnet.spoke1_default.id
  network_security_group_id = azurerm_network_security_group.zero_trust.id
}

The priority gap (100 → 4096) leaves room for hundreds of application-specific rules without renumbering the baseline.

Centralized Private DNS

Deploy DNS zones once in the Hub — Spokes resolve through peering automatically:

variable "private_dns_zones" {
  default = [
    "privatelink.blob.core.windows.net",
    "privatelink.database.windows.net",
    "privatelink.vaultcore.azure.net",
    "privatelink.azurecr.io"
  ]
}

resource "azurerm_private_dns_zone" "enterprise_zones" {
  for_each            = toset(var.private_dns_zones)
  name                = each.key
  resource_group_name = azurerm_resource_group.rg.name

  lifecycle {
    ignore_changes = [tags["hidden-title"], tags["CreatedByPolicy"]]
  }
}

Four zones, one block, DINE-proof. No per-Spoke DNS configuration required.

The free base topology is on GitHub. The full article with complete DINE bypass logic, NSG associations, and VNet link protection is on my blog.

👉 Full article on woitzik.dev
👉 Free GitHub repo

Hardening Azure Acmebot for ISO 27001 & NIS2 Compliance with Terraform

david — Sat, 16 May 2026 22:00:00 +0000

Automating SSL/TLS certificates with Let's Encrypt and Azure Key Vault is a solved problem. Tools like Azure Acmebot make deployment incredibly simple.

In corporate environments targeting ISO 27001, KRITIS, or NIS2 compliance, "simple" is rarely sufficient. The standard Acmebot deployment relies on public endpoints — and a Storage Account or Key Vault reachable from the public internet will immediately trigger findings during a security audit.

Here's how to transition from a standard deployment to a fully network-isolated, Zero-Trust architecture — entirely managed with Terraform.

The Compliance Gap

Three components expose a public attack surface out of the box:

Storage Account — accepts traffic from all networks by default
Key Vault — operates with a public endpoint unless explicitly restricted
Function App — the Acmebot dashboard is publicly reachable with no network-layer restriction

Target principle: Default-Deny at the network layer, not just the identity layer.

Step 1: VNet Integration

The Function App needs a dedicated subnet with a delegation to Microsoft.Web/serverFarms:

resource "azurerm_subnet" "acmebot_integration" {
  name                 = "snet-acmebot-integration"
  resource_group_name  = var.existing_vnet_rg
  virtual_network_name = var.existing_vnet_name
  address_prefixes     = ["10.0.1.0/27"]

  delegation {
    name = "delegation-acmebot"
    service_delegation {
      name    = "Microsoft.Web/serverFarms"
      actions = ["Microsoft.Network/virtualNetworks/subnets/join/action"]
    }
  }
}

Two settings that will cost you hours if you miss them:

site_config {
  vnet_route_all_enabled = true  # Forces ALL outbound through VNet
}

app_settings = {
  "WEBSITE_DNS_SERVER"      = "168.63.129.16"  # Azure internal DNS — required
  "WEBSITE_CONTENTOVERVNET" = "1"
}

Without vnet_route_all_enabled = true, the Function still tries to reach Storage over the public internet and fails silently once you lock it down.

Step 2: Private Endpoints & DNS

The Storage Account requires four separate Private Endpoints — one each for blob, table, queue, and file. Azure Functions uses all four internally. Skip any one and the Function App deploys successfully but fails at runtime with cryptic storage errors:

resource "azurerm_private_endpoint" "storage_pe" {
  for_each  = toset(["blob", "table", "queue", "file"])
  name      = "pe-acmebot-st-${each.key}"
  subnet_id = azurerm_subnet.acmebot_endpoints.id

  private_service_connection {
    name                           = "psc-acmebot-st-${each.key}"
    private_connection_resource_id = azurerm_storage_account.acmebot_storage.id
    subresource_names              = [each.key]
    is_manual_connection           = false
  }

  private_dns_zone_group {
    name                 = "default"
    private_dns_zone_ids = [var.private_dns_zone_ids[each.key]]
  }
}

Step 3: Default-Deny Firewall Rules

resource "azurerm_storage_account" "acmebot_storage" {
  public_network_access_enabled   = false
  allow_nested_items_to_be_public = false

  network_rules {
    default_action             = "Deny"
    bypass                     = ["AzureServices"]
    virtual_network_subnet_ids = [azurerm_subnet.acmebot_integration.id]
  }
}

bypass = "AzureServices" is required — it allows Azure's internal control plane operations to continue working. Without it, diagnostic log shipping and other platform features silently break.

After applying this configuration, your Acmebot deployment meets the network isolation requirements of ISO 27001 Annex A.8, NIS2 Article 21, and KRITIS baseline controls.

The complete tested architecture including Entra ID automation and full Private Link configuration is on my blog and GitHub.

👉 Full article on woitzik.dev
👉 Free GitHub repo

Breaking the Loop: Solving Circular Dependencies in Azure Firewall Routing with Terraform

david — Fri, 15 May 2026 20:39:45 +0000

You add a Route Table to force all internet-bound traffic (0.0.0.0/0) from your Spoke VNets into an Azure Firewall. You run terraform plan.

Error: Cycle: azurerm_subnet_route_table_association.spoke_binding,
azurerm_route_table.spoke_udr, azurerm_firewall.fw ...

Terraform has deadlocked. And even if you fix the cycle — a plain 0.0.0.0/0 route will silently break Windows VM activation and Managed Identity authentication three days later.

Here's why both happen and how to fix them cleanly.

The Cycle Error

Terraform can't resolve the dependency graph:

The Route Table needs the Firewall's private_ip_address
The Firewall needs AzureFirewallSubnet to exist first
The Subnet Association tries to bind everything simultaneously

The fix: directly reference azurerm_firewall.fw.ip_configuration[0].private_ip_address in the Route Table. Terraform can now unambiguously resolve the order:

Firewall → (has IP) → Route Table → Subnet Association

No workarounds. Just correct resource ordering.

The PaaS Trap

Once the cycle is fixed, most engineers celebrate and move on. Three days later:

Windows VMs lose activation — Azure KMS traffic is trapped by 0.0.0.0/0
Managed Identities stop authenticating — Azure AD traffic hits the unconfigured firewall

The fix is two explicit bypass routes that must exist before the Route Table is attached to any subnet:

# KMS Bypass — required for Windows VM activation
# 23.102.135.246/32 is Azure's global KMS endpoint (officially documented)
route {
  name           = "bypass-azure-kms"
  address_prefix = "23.102.135.246/32"
  next_hop_type  = "Internet"
}

# Azure AD Bypass — prevents Managed Identity auth lockouts
route {
  name           = "bypass-azure-ad"
  address_prefix = "AzureActiveDirectory"
  next_hop_type  = "Internet"
}

Note: next_hop_type = "Internet" for Azure-owned IP ranges routes traffic over Azure's internal backbone — it never leaves Microsoft's network.

Scaling to Multiple Spokes

Instead of duplicating the association resource for every Spoke, use for_each:

resource "azurerm_subnet_route_table_association" "spoke_routing" {
  for_each       = var.spoke_subnet_ids
  subnet_id      = each.value
  route_table_id = azurerm_route_table.spoke_udr.id
}

Add a new Spoke to the variable map, run terraform apply — done.

The free baseline (cycle fix + route table structure) is on GitHub. The full article with complete code, IP Group scaling, and FQDN baseline policies is on my blog.

👉 Full article on woitzik.dev

👉 Free GitHub repo