Variaties in firewallregels binnen Azure Resource Manager begrijpen

Introductie

Het waarborgen van veilige deployments in Microsoft Azure vereist consistent en afdwingbaar firewallbeleid. Azure Resource Manager (ARM) vormt de basis voor resourcebeheer, maar inconsistenties in de manier waarop firewallregels worden geïmplementeerd zorgen voor uitdagingen bij het afdwingen van beleid. Sommige resources hebben firewallinstellingen ingebed in hun netwerkeigenschappen, waardoor beleid direct kan worden toegepast, terwijl andere firewallregels behandelen als aparte child-resources — waardoor Deny-beleid niet effectief is wanneer publieke netwerktoegang is ingeschakeld. Deze inconsistenties bemoeilijken het definiëren en afdwingen van beveiligingsmaatregelen, waardoor er gaten in de beleidsdekking ontstaan.

In dit artikel onderzoeken we deze variaties in firewallregelconfiguraties en verkennen we de moeilijkheden die ze met zich meebrengen voor beleidsafdwinging.

Verschillen in firewallregelimplementaties

Firewallconfiguraties in ARM kunnen variëren per resourcetype. Sommige worden gedefinieerd binnen de resource-eigenschappen, terwijl andere bestaan als onafhankelijke child-resources. Dit verschil beïnvloedt hoe beleid, met name Deny-beleid, wordt toegepast.

Firewallregels voor Storage Accounts

Bij Storage Accounts worden firewallinstellingen gedefinieerd als onderdeel van de netwerkeigenschappen van de resource. Dit betekent dat beleid gericht op netwerktoegang direct op de resource kan worden toegepast. Als bonus ondersteunt deze resource een defaultAction. Dit betekent dat je als platformteam de ipRules kunt voorladen met bekende bedrijfs-IP-adressen zonder de firewall te activeren. Ja, je kunt de defaultAction op ‘Allow’ zetten en tegelijkertijd de ipRules instellen.

properties: {
  networkAcls: {
    bypass: 'string'
    defaultAction: 'string'
    ipRules: [
      {
        action: 'Allow'
        value: 'string'
      }
    ]
}

Kijk nu naar de firewallinstellingen voor een EventGrid/namespace:

properties: {
  inboundIpRules: [
    {
      action: 'string'
      ipMask: 'string'
    }
  ]
}

Deze resource heeft geen defaultAction-eigenschap. Dit betekent dat de firewall automatisch wordt geactiveerd zodra je de eerste firewallregel toevoegt. In dit geval kunnen we de resource niet voorladen met bekende bedrijfs-IP-adressen.

Merk ook op dat het value-veld hier ipMask heet. De implementaties in ARM zijn inconsistent. De structurele verschillen in firewallregels tussen resourcetypen maken het onmogelijk om een universeel beleid op te stellen dat van toepassing is op meerdere resourcetypen.

Er zijn nog meer inconsistenties in firewallimplementaties. Kun jij ze allemaal vinden?

Firewallregels voor SQL Server

Dan de SQL Server-firewallregel:

resource symbolicname 'Microsoft.Sql/servers/firewallRules@2024-05-01-preview' = {
  parent: resourceSymbolicName
  name: 'string'
  properties: {
    endIpAddress: 'string'
    startIpAddress: 'string'
  }
}

Bij SQL Servers worden firewallregels geïmplementeerd als child-resources (Microsoft.Sql/servers/firewallRules), waardoor afdwinging via een Deny-beleid onmogelijk is.

Conclusie

Deze inconsistenties in ARM-firewallconfiguraties kunnen impact hebben op beveiligingsbeleid, toegangscontrole en governancestrategieën. DevOps-engineers en IT-managers moeten deze variaties herkennen om beveiliging effectief af te dwingen.

Heb jij uitdagingen ondervonden door deze verschillen?

---