If an application handles sensitive information and does not use message-level encryption, then it should only be allowed to communicate over an encrypted transport channel.

If an application handles sensitive information and does not use message-level encryption, then it should only be allowed to communicate over an encrypted transport channel. The <transportSender> tag should not specify http, because communication with this URL will not be encrypted.

By default, Azure Blob Storage containers prevent anonymous access to their Blobs.

Insufficient access configurations expose systems and broaden an organization's attack surface. Resources open to public access might unintentionally leak sensitive data.

Example 1: The following example Ansible task defines an Azure Blob Storage container with the public_access parameter set to container. This allows anonymous access to all of the Container's blobs and data.

- name: Create container test
  azure_rm_storageblob:
    resource_group: testGroup
    storage_account_name: sa001
    container: testContainer
    ...
    public_access: container
    ...

Overly broad configurations expose systems and broaden an organization's attack surface. Services open to interaction with the public are subjected to almost continuous scanning and probing by attackers.

This is especially problematic when a zero-day exploit for an exposed service is discovered and published (e.g. Heartbleed). Attackers can actively pursue and search for unpatched and exposed systems to exploit.

Example 1: The following example Ansible task allows unrestricted inbound traffic to a range of ports, including the RDP service port (3389).

- name: testFWRule
    azure_rm_securitygroup:
        resource_group: testRG
        name: test
        rules:
        - name: rule001
            priority: 100
            direction: Inbound
            access: Allow
            protocol: "*"
            source_port_range: "*"
            destination_port_range: "3388-3398"
            source_address_prefix: "*"
            destination_address_prefix: "*"
        - name: rule002
            priority: 100
            direction: Inbound
            access: Allow
            protocol: "*"
            source_port_range: "*"
            destination_port_range: 22
            source_address_prefix: "*"
            destination_address_prefix: "*"

By default, Azure storage accounts created by Ansible accept connections from clients on any network.

Loose access configurations unnecessarily expose systems and broaden an organization's attack surface. Services open to interaction with the public are subjected to almost continuous scanning and probing by malicious entities.

Example 1: The following example Ansible task fails to restrict network access to an Azure storage account.

- name: storage with network acl
    azure_rm_storageaccount:
      resource_group: testGroup
      name: sa001
      type: Standard_RAGRS
      network_acls:
        bypass: AzureServices,Metrics
        default_action: Deny
        ip_rules:
          - value: 0.0.0.0/0
            action: Allow

By default, Ansible tasks do not enable Azure MySQL Database transport encryption (as per Azure.Azcollection v1.11.0 and earlier).

Unencrypted communication channels are prone to eavesdropping and tampering.

Disabling transport security exposes the data to unauthorized access, potential theft, and tampering.

Example 1: The following example Ansible task defines an Azure MySQL Database with transport encryption disabled.

- name: Create MySQL Server
    azure.azcollection.azure_rm_mysqlserver:
        resource_group: testGroup
        name: testMySQL
        sku:
        name: B_Gen5_1
        tier: Basic
        location: westeurope
        storage_mb: 8096
        version: 5.6
        enforce_ssl: false
        admin_username: test
        admin_password: complicatedPass

By default, Ansible tasks do not enable Azure Database for PostgreSQL transport encryption (as per Azure.Azcollection v1.11.0 and earlier).

Unencrypted communication channels are prone to eavesdropping and tampering.

Disabling transport security exposes the data to unauthorized access, potential theft, and tampering.

Example 1: The following example Ansible task defines an Azure Database for PostgreSQL with transport encryption disabled.

- name: Create Postgres Server
  azure.azcollection.azure_rm_postgresqlserver:
    resource_group: testGroup
    name: testPostgres
    sku:
      name: B_Gen5_1
      tier: Basic
    location: westeurope
    storage_mb: 8096
    version: 5.6
    enforce_ssl: false
    admin_username: test
    admin_password: complicatedPass

Unencrypted communication channels are prone to eavesdropping and tampering.

By default, the https_only setting is set to yes enforcing secure transfer for an Azure storage account. However, this setting can be explicitly disabled.

Disabling secure transfer exposes the stored data to unauthorized access, potential theft, and tampering.

Example 1: The following Ansible task shows a storage account that does not enforce secure transfer.

- name: create a storage account
  azure_rm_storageaccount:
    resource_group: testResGroup
    name: sa0001
    type: Standard_GRS
    https_only: no

By default, Azure Kubernetes Service (AKS) clusters created by Ansible do not send log events to Azure Monitor. This can allow malicious behavior to go undetected and prevent forensic analysis in the event of a breach.

Example 1: The following example Ansible task shows an AKS cluster that does not send log events to Azure Monitor.

- name: AKS Instance
  azure_rm_aks:
    name:
    resource_group: testResourceGroup
    location: eastus
    ...
    addon:
      monitoring:
        log_analytics_workspace_resource_id: logws001
        enabled: no

A lack of audit records limits the ability to detect and respond to security related incidents and prevents forensic investigation.

Sensitive Azure ARM template parameters, such as passwords, typically use the @secure() decorator.

For parameters that use the @secure() decorator, the parameter values are not logged or stored in the deployment history.

However, if a hardcoded default value is configured for a secure type, that default value is discoverable to anyone who can access the template or the deployment history.

Hard-coded secrets can compromise security in a way that is not easy to remedy. After the software is in production, an update is required to change the compromised secret.

In the case of a secret that is used to encrypt data, key-rotation steps must be administered to decrypt and re-encrypt all the data protected by the compromised key.

Example 1: The following template shows a parameter with a secret type that has a hardcoded default value.

@secure()
param rootPassword string = 'HardcodedPassword'

param adminLogin string
param sqlServerName string
...

All data sent over HTTP is visible and subject to compromise.
Example 1:

"supportsHttpsTrafficOnly": "false"

A publicly accessible Kubernetes API server can expose the organization to attack.

Example 1: The following example shows a template that defines a Kubernetes service cluster that does not restrict the range of IP addresses that are allowed to connect to the API server.

param location string = resourceGroup().location

resource example 'Microsoft.ContainerService/managedClusters@2020-02-01' = {
    name: 'TestCluster'
    location: location
    properties: {
        ...
        servicePrincipalProfile: {
            clientId: '422313d8-123a-41ea-8f8e-90821ff61c05'
            secret: 'xxxxxxxxxxxxxxxxx'
        }
    }
}

Debugging interfaces provide attackers with information that they can leverage for a more targeted attack.

Example 1: The following example template defines an Azure App Service with remote debugging enabled.

resource example 'Microsoft.Web/sites/config@2022-09-01' = {
    ...
    properties: {
        ...
        remoteDebuggingEnabled: true
    }
}

By default, Azure Blob Storage containers prevent anonymous access to their Blobs.

Insufficient access configurations expose systems and broaden an organization's attack surface. Resources open to public access might unintentionally leak sensitive data.

Example 1: The following example template defines an Azure Blob Storage container with the publicAccess property set to Container. This allows anonymous access to all of the container's blobs and data.

param storageAccountName string
param containerName string

resource example 'Microsoft.Storage/storageAccounts/blobServices/containers@2021-04-01' = {
    name: '${storageAccountName}/default/${containerName}'
    ...
    properties: {
        ...
        publicAccess: 'Container'
    }
}

Insufficient access configurations expose systems and broaden an organization's attack surface. Services open to interaction with the internet are subject to continuous scanning and probing by malicious entities.

This is especially problematic when a zero-day exploit for an exposed service is discovered and published (e.g Heartbleed). Attackers can actively pursue and search for unpatched and exposed systems to exploit.

Example 1: The following example template defines an Azure Container Registry with unrestricted network access by enabling the property publicNetworkAccess and making no IP restrictions.

resource example 'Microsoft.ContainerRegistry/registries@2022-12-01' = {
    ...
    properties: {
        ...
        publicNetworkAccess: 'Enabled'
    }
}

Example 2: The following example template defines an Azure Container Registry with unrestricted network access by specifying a broad allow list for the networkRuleSet property.

resource example 'Microsoft.ContainerRegistry/registries@2022-12-01' = {
    ...
    properties: {
        ...
        publicNetworkAccess: 'Enabled'
        networkRuleSet: {
            defaultAction: 'Allow'
            ipRules: [
                {
                    action: 'Allow'
                    value: '*'
                }
            ]
        }
    }
}

Cross-Origin Resource Sharing, commonly referred to as CORS, is a technology that allows a domain to define a policy for its resources to be accessed by a web page hosted on a different domain. Historically, web browsers have restricted their domain resources from being accessed by scripts loaded from a different domain to abide by the same origin policy.
CORS provides a method for a domain to allow other domains and enable them to access its resources.

Be careful when defining a CORS policy because an overly permissive policy configured at the server level for a domain or a directory on a domain can expose more content for cross domain access than intended. CORS can enable a malicious application to communicate with a victim application inappropriately, which can lead to information disclosure, spoofing, data theft, relay, or other attacks.

Implementing CORS can increase an application's attack surface and should only be used when necessary.

Example 1: The following example template defines an overly permissive CORS policy for an Azure SignalR web application.

resource example 'Microsoft.SignalRService/SignalR@2022-02-01' = {
    ...
    properties: {
        ...
        cors: {
            ...
            allowedOrigins: [ '*' ]
        }
    }
}

Example 2: The following example template defines an overly permissive CORS policy for an Azure web application.

resource example 'Microsoft.Web/sites@2020-12-01' = {
    ...
    properties: {
        ...
        siteConfig: {
            ...
            cors: {
                ...
                allowedOrigins: [ '*' ]
            }
        }
    }
}

Example 3: The following example template defines an overly permissive CORS policy for an Azure Maps account.

resource example 'Microsoft.Maps/accounts@2021-12-01-preview' = {
    ...
    properties: {
        ...
        cors: {
            corsRules: [
                {
                    allowedOrigins: [ '*' ]
                }
            ]
        }
    }
}

Example 4: The following example template defines an overly permissive CORS policy for an Azure Cosmos DB account.

resource example 'Microsoft.DocumentDB/databaseAccounts@2023-04-15' = {
    ...
    properties: {
        ...
        cors: [
            {
                ...
                allowedOrigins: '*'
            }
        ]
    }
}

Example 5: The following example template defines an overly permissive CORS policy for an Azure storage blob service.

resource example 'Microsoft.Storage/storageAccounts/blobServices@2021-09-01' = {
    ...
    properties: {
        ...
        cors: {
            corsRules: [
                {
                    ...
                    allowedOrigins: [ '*' ]
                }
            ]
        }
    }
}

Relaxed access configurations expose systems and broaden an organization's attack surface. Services open to interaction with the internet are subjected to almost continuous scanning and probing by malicious entities.

This is especially problematic when a zero-day exploit for an exposed service is discovered and published (e.g Heartbleed). Attackers can actively pursue and search for unpatched and exposed systems to exploit.

Example 1: The following example template defines an Azure Cosmos DB with unrestricted network access. The publicNetworkAccess property is set to Enabled and the IP address range includes all IPs.

resource example 'Microsoft.DocumentDB/databaseAccounts@2021-04-15' = {
    ...
    properties: {
        ...
        publicNetworkAccess: 'Enabled'
        ipRules: [
            {
                ipAddressOrRange: '0.0.0.0'
            }
        ]
    }
}

Overly broad configurations expose systems and broaden an organization's attack surface. Services open to interaction with the public are subjected to almost continuous scanning and probing by attackers.

This is especially problematic when a zero-day exploit for an exposed service is discovered and published (e.g. Heartbleed). Attackers can actively pursue and search for unpatched and exposed systems to exploit.

Example 1: The following example template allows unrestricted inbound traffic to a range of ports, including the RDP service port (3389).

resource example 'Microsoft.Network/networkSecurityGroups/securityRules@2020-11-01' = {
    ...
    properties: {
        ...
        description: 'Services Inbound Range'
        protocol: 'Tcp'
        sourcePortRange: '*'
        destinationPortRanges: [ '3333-3389' ]
        sourceAddressPrefix: '*'
        destinationAddressPrefix: '*'
        access: 'Allow'
        priority: 100
        direction: 'Inbound'
    }
}

Azure SQL Database instances with unrestricted ranges of allowable IP addresses unnecessarily broaden an organization's attack surface. Services open to interaction with the public are subjected to almost continuous scanning and probing by attackers.

Example 1: The following example template defines an overly exposed Azure SQL Database instance.

resource example 'Microsoft.Sql/servers@2021-11-01' = {
    ...
    resource fwRules 'firewallRules' = {
        properties: {
            startIpAddress: '0.0.0.0'
            endIpAddress: '255.255.255.255'
        }
    }
}