Using a password type of PasswordText might be an indication that actual passwords are being transmitted in plain text. The WS-Security UsernameToken Profile states that text sent in the UsernameToken <Password> tag are not limited to being actual passwords. They can be password derivatives instead. However, it is common for developers to send actual passwords instead of password derivatives. Sending unencrypted passwords or even password hashes exposes the credentials to anyone with a traffic sniffer.

Sending plain text passwords or password hashes over an unencrypted channel can expose the credential to attackers who can sniff the SOAP message.

Example 1: The following Axis client configuration uses the UsernameToken:

<deployment xmlns="http://xml.apache.org/axis/wsdd/" xmlns:java="http://xml.apache.org/axis/wsdd/providers/java">
...
	<parameter name="action" value="UsernameToken"/>
...
</deployment>

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

Unencrypted communication channels are prone to eavesdropping and tampering.

Serving web applications over HTTP allows attackers to perform man-in-the-middle attacks, giving them access to read or modify the data in transit over the channel.

Example 1: The following example shows an Ansible task that defines an Azure App Service that does not enforce HTTPS communication.

- name: app service
  azure_rm_webapp:
    resource_group: testGroup
    name: testApp
    https_only: false
    ...

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.

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 Ansible task defines an overly exposed Azure SQL Database instance.

- name: Create Firewall Rule
  azure.azcollection.azure_rm_sqlfirewallrule:
    resource_group: orgTestGroup
    server_name: orgSQLServer
    name: SQLServerFWRule
    start_ip_address: 0.0.0.0
    end_ip_address: 255.255.255.255

Customer-managed keys are not used to encrypt data at rest.

Customer-managed keys enable organizations to use cryptographic keys of their choice to encrypt data. This gives organizations better control over encryption processes.

As such, customer-managed keys are often part of the solution to address requirements that include but are not limited to:
- Audit logs for sensitive data access
- Data residency
- Replacing, disabling, or destroying keys

Customer-managed keys are not used to encrypt data at rest.

Customer-managed keys enable organizations to use cryptographic keys of their choice to encrypt data. This gives organizations better control over encryption processes.

As such, customer-managed keys are often part of the solution to address requirements that include but are not limited to:
- Audit logs for sensitive data access
- Data residency
- Replacing, disabling, or destroying keys

Customer-managed keys are not used to encrypt data at rest.

Customer-managed keys enable organizations to use cryptographic keys of their choice to encrypt data. This gives organizations better control over encryption processes.

As such, customer-managed keys are often part of the solution to address requirements that include but are not limited to:
- Audit logs for sensitive data access
- Data residency
- Replacing, disabling, or destroying keys

Customer-managed keys are not used to encrypt data at rest.

Customer-managed keys enable organizations to use cryptographic keys of their choice to encrypt data. This gives organizations better control over encryption processes.

As such, customer-managed keys are often part of the solution to address requirements that include but are not limited to:
- Audit logs for sensitive data access
- Data residency
- Replacing, disabling, or destroying keys

Customer-managed keys are not used to encrypt data at rest.

Customer-managed keys enable organizations to use cryptographic keys of their choice to encrypt data. This gives organizations better control over encryption processes.

As such, customer-managed keys are often part of the solution to address requirements that include but are not limited to:
- Audit logs for sensitive data access
- Data residency
- Replacing, disabling, or destroying keys

Sensitive Azure ARM template parameters, such as passwords, typically use the securestring or secureobject types.

For parameters that use a secure type, 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 readable 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.

{
    ...
    "parameters": {
        "rootPassword": {
            "defaultValue": "HardcodedPassword",
            "type": "secureString"
        },
        "adminLogin": {
            "type": "string"
        },
        "sqlServerName": {
            "type": "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'
        }
    }
}