De forma predeterminada, los contenedores de almacenamiento de blobs de Azure impiden el acceso anónimo a sus blobs.

Las configuraciones de acceso insuficientes exponen los sistemas y amplían la superficie de ataque de una organización. Los recursos abiertos al acceso público pueden filtrar involuntariamente datos confidenciales.

Ejemplo 1: La siguiente tarea de Ansible de ejemplo define un contenedor de almacenamiento de blobs de Azure con el parámetro public_access establecido en container. Esto permite el acceso anónimo a todos los blobs y datos del contenedor.

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

Las configuraciones demasiado amplias exponen los sistemas y amplían la superficie de ataque de una organización. Los servicios abiertos a la interacción con el público están sujetos a análisis y sondeos casi continuos por parte de los atacantes.

Esto es especialmente problemático cuando se descubre y publica una vulnerabilidad de día cero para un servicio expuesto (por ejemplo, Heartbleed). Los atacantes pueden perseguir y buscar activamente sistemas expuestos y sin revisión que puedan aprovechar.

Ejemplo 1: La siguiente tarea de Ansible de ejemplo permite el tráfico entrante sin restricciones a una variedad de puertos, incluido el puerto de servicio RDP (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: "*"

De forma predeterminada, las cuentas de almacenamiento de Azure creadas por Ansible aceptan conexiones de clientes en cualquier red.

Las configuraciones de acceso dinámico exponen innecesariamente los sistemas y amplían la superficie de ataque de una organización. Los servicios abiertos a la interacción con el público están sujetos a análisis y sondeos casi continuos por parte de entidades malintencionadas.

Ejemplo 1: La siguiente tarea de Ansible de ejemplo no puede restringir el acceso a la red a una cuenta de almacenamiento de Azure.

- 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

Los canales de comunicación no cifrados son propensos al espionaje y manipulaciones.

El servicio de aplicaciones web a través de HTTP permite a los atacantes realizar ataques "man-in-the-middle", dándoles acceso para leer o modificar los datos en tránsito por el canal.

Ejemplo 1: El siguiente ejemplo muestra una tarea de Ansible que define un Azure App Service que no aplica la comunicación HTTPS.

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

De forma predeterminada, las tareas de Ansible no habilitan el cifrado de transporte de la Azure MySQL Database (según Azure.Azcollection v1.11.0 y versiones anteriores).

Los canales de comunicación no cifrados son propensos al espionaje y manipulaciones.

Deshabilitar la seguridad del transporte expone los datos a accesos no autorizados, posibles robos y manipulaciones.

Ejemplo 1: La siguiente tarea de Ansible de ejemplo define una Azure MySQL Database con el cifrado de transporte deshabilitado.

- 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

De forma predeterminada, las tareas de Ansible no habilitan el cifrado de transporte de una Azure Database for PostgreSQL (según Azure.Azcollection v1.11.0 y versiones anteriores).

Los canales de comunicación no cifrados son propensos al espionaje y manipulaciones.

Deshabilitar la seguridad del transporte expone los datos a accesos no autorizados, posibles robos y manipulaciones.

Ejemplo 1: La siguiente tarea de Ansible de ejemplo define una Azure Database for PostgreSQL con el cifrado de transporte deshabilitado.

- 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

Los canales de comunicación no cifrados son propensos al espionaje y manipulaciones.

Por defecto, el ajuste https_only se establece en yes, lo que garantiza una transferencia segura para una cuenta de almacenamiento de Azure. Sin embargo, este ajuste se puede deshabilitar explícitamente.

La desactivación de la transferencia segura expone los datos almacenados a accesos no autorizados, posibles robos y manipulaciones.

Ejemplo 1: La siguiente tarea de Ansible muestra una cuenta de almacenamiento que no aplica una transferencia segura.

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

De forma predeterminada, los clústeres de Azure Kubernetes Service (AKS) creados por Ansible no envían eventos de registro a Azure Monitor. Esto puede permitir que el comportamiento malintencionado no se detecte y evitar el análisis forense en caso de infracción.

Ejemplo 1: La siguiente tarea de Ansible de ejemplo muestra un clúster de AKS que no envía eventos de registro a Azure Monitor.

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

La ausencia de registros de auditoría limita la capacidad de detectar y responder a incidentes relacionados con la seguridad e impide la investigación forense.

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

Las claves administradas por el cliente no se utilizan para cifrar datos en reposo.

Las claves administradas por el cliente permiten a las organizaciones usar claves criptográficas de su elección para cifrar datos. Esto brinda a las organizaciones un mejor control de los procesos de cifrado.

De este modo, las claves administradas por el cliente suelen ser parte de la solución para satisfacer requisitos que incluyen, entre otros:
- Registros de auditoría para el acceso a datos confidenciales
- Residencia de datos
- Reemplazo, deshabilitación o destrucción de claves

Las claves administradas por el cliente no se utilizan para cifrar datos en reposo.

Las claves administradas por el cliente permiten a las organizaciones usar claves criptográficas de su elección para cifrar datos. Esto brinda a las organizaciones un mejor control de los procesos de cifrado.

De este modo, las claves administradas por el cliente suelen ser parte de la solución para satisfacer requisitos que incluyen, entre otros:
- Registros de auditoría para el acceso a datos confidenciales
- Residencia de datos
- Reemplazo, deshabilitación o destrucción de claves

Las claves administradas por el cliente no se utilizan para cifrar datos en reposo.

Las claves administradas por el cliente permiten a las organizaciones usar claves criptográficas de su elección para cifrar datos. Esto brinda a las organizaciones un mejor control de los procesos de cifrado.

De este modo, las claves administradas por el cliente suelen ser parte de la solución para satisfacer requisitos que incluyen, entre otros:
- Registros de auditoría para el acceso a datos confidenciales
- Residencia de datos
- Reemplazo, deshabilitación o destrucción de claves

Las claves administradas por el cliente no se utilizan para cifrar datos en reposo.

Las claves administradas por el cliente permiten a las organizaciones usar claves criptográficas de su elección para cifrar datos. Esto brinda a las organizaciones un mejor control de los procesos de cifrado.

De este modo, las claves administradas por el cliente suelen ser parte de la solución para satisfacer requisitos que incluyen, entre otros:
- Registros de auditoría para el acceso a datos confidenciales
- Residencia de datos
- Reemplazo, deshabilitación o destrucción de claves

Las claves administradas por el cliente no se utilizan para cifrar datos en reposo.

Las claves administradas por el cliente permiten a las organizaciones usar claves criptográficas de su elección para cifrar datos. Esto brinda a las organizaciones un mejor control de los procesos de cifrado.

De este modo, las claves administradas por el cliente suelen ser parte de la solución para satisfacer requisitos que incluyen, entre otros:
- Registros de auditoría para el acceso a datos confidenciales
- Residencia de datos
- Reemplazo, deshabilitación o destrucción de claves

Los parámetros confidenciales de la plantilla de Azure ARM, como las contraseñas, suelen utilizar los tipos securestring osecureobject.

Para los parámetros que utilizan un tipo seguro, los valores de los parámetros no se registran ni almacenan en el historial de implementación.

Sin embargo, si un valor predeterminado codificado de forma rígida se configura para un tipo seguro, ese valor predeterminado es legible para cualquiera que pueda acceder a la plantilla o al historial de implementación.

Los secretos con codificación rígida pueden poner en riesgo la seguridad de una forma que no es fácil resolver. Una vez que el software está en fase de producción, se requiere una actualización para cambiar el secreto comprometido.

En el caso de un secreto que se utiliza para cifrar datos, se deben administrar los pasos de rotación de claves para descifrar y volver a cifrar todos los datos protegidos por la clave comprometida.

Ejemplo 1: La siguiente plantilla muestra un parámetro con un tipo secreto que tiene un valor predeterminado codificado de forma rígida.

{
    ...
    "parameters": {
        "rootPassword": {
            "defaultValue": "HardcodedPassword",
            "type": "secureString"
        },
        "adminLogin": {
            "type": "string"
        },
        "sqlServerName": {
            "type": "string"
        }
    },
    ...
}

Todos los datos enviados a través de HTTP son visibles y pueden estar en riesgo.
Ejemplo 1:

"supportsHttpsTrafficOnly": "false"

Un servidor API de Kubernetes de acceso público puede exponer la organización a un ataque.

Ejemplo 1: El siguiente ejemplo muestra una plantilla que define un clúster de servicios de Kubernetes que no restringe el rango de direcciones IP que pueden conectarse al servidor API.

{
    "name": "TestCluster",
    "type": "Microsoft.ContainerService/managedClusters",
    "apiVersion": "2020-02-01",
    "location": "[resourceGroup().location]",
    "properties": {
    ...
    "servicePrincipalProfile": {
        "clientId": "422313d8-123a-41ea-8f8e-90821ff61c05",
        "secret": "xxxxxxxxxxxxxxxxx"
    },
    }
}

Las interfaces de depuración proporcionan información a los atacantes, la cual estos pueden aprovechar para un ataque más dirigido.

Ejemplo 1: La siguiente plantilla de ejemplo define un Azure App Service con la depuración remota habilitada.

{
    ...
    "type": "Microsoft.Web/sites/config",
    "properties":
    {
        ...
        "remoteDebuggingEnabled": true,
    }
}

De forma predeterminada, los contenedores de almacenamiento de blobs de Azure impiden el acceso anónimo a sus blobs.

Las configuraciones de acceso insuficientes exponen los sistemas y amplían la superficie de ataque de una organización. Los recursos abiertos al acceso público pueden filtrar involuntariamente datos confidenciales.

Ejemplo 1: La siguiente plantilla de ejemplo define un contenedor de almacenamiento de blobs de Azure con la propiedad publicAccess establecida en Container. Esto permite el acceso anónimo a todos los blobs y datos del contenedor.

{
    "type": "Microsoft.Storage/storageAccounts/blobServices/containers",
    "apiVersion": "2021-04-01",
    "name": "[format('{0}/default/{1}', parameters('storageAccountName'), parameters('containerName'))]",
    "properties":{
        "publicAccess": "Container"
    }
    ,
    "dependsOn": [
        "[resourceId('Microsoft.Storage/storageAccounts', parameters('storageAccountName'))]"
    ]
}