Por padrão, os contêineres de armazenamento de Blob do Azure evitam o acesso anônimo a seus Blobs.

As configurações de acesso insuficientes expõem os sistemas e ampliam a superfície de ataque de uma organização. Os recursos abertos ao acesso público podem vazar acidentalmente dados confidenciais.

Exemplo 1: A tarefa do Ansible de exemplo a seguir define um contêiner de Armazenamento de Blobs do Azure com o parâmetro public_access definido como container. Isso permite acesso anônimo a todos os blobs e dados do Contêiner.

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

Configurações excessivamente amplas expõem os sistemas e ampliam a superfície de ataque de uma organização. Os serviços abertos à interação com o público estão sujeitos a varreduras e investigações quase contínuas por parte dos invasores.

Isso é especialmente problemático quando um exploit de dia zero para um serviço exposto é descoberto e publicado (por exemplo, Heartbleed). Os invasores podem perseguir e pesquisar ativamente sistemas não corrigidos e expostos para explorá-los.

Exemplo 1: A tarefa do Ansible de exemplo a seguir permite tráfego de entrada irrestrito para um intervalo de portas, incluindo a porta de serviço 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: "*"

Por padrão, as contas de armazenamento do Azure criadas pelo Ansible aceitam conexões de clientes em qualquer rede.

As configurações de acesso livre expõem os sistemas desnecessariamente e ampliam a superfície de ataque de uma organização. Os serviços abertos à interação com o público estão sujeitos a varreduras e investigações quase contínuas por entidades mal-intencionadas.

Exemplo 1: A tarefa do Ansible de exemplo a seguir não restringe o acesso à rede de uma conta de armazenamento do 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

Canais de comunicação não criptografados estão propensos a serem interceptados e adulterados.

Atender aplicativos da web por HTTP permite que os invasores executem ataques man-in-the-middle, dando-lhes acesso para ler ou modificar os dados em trânsito pelo canal.

Exemplo 1: O exemplo a seguir mostra uma tarefa do Ansible que define um Serviço de Aplicativo do Azure que não impõe a comunicação HTTPS.

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

Por padrão, as tarefas do Ansible não habilitam a criptografia de transporte do Banco de Dados MySQL do Azure (conforme o Azure.Azcollection v1.11.0 e anterior).

Canais de comunicação não criptografados estão propensos a serem interceptados e adulterados.

Desativar a segurança de transporte expõe os dados a acesso não autorizado, possível roubo e adulteração.

Exemplo 1: A tarefa do Ansible de exemplo a seguir define um Banco de Dados MySQL do Azure com criptografia de transporte desabilitada.

- 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

Por padrão, as tarefas do Ansible não habilitam a criptografia de transporte do Banco de Dados do Azure para PostgreSQL (conforme o Azure.Azcollection v1.11.0 e anterior).

Canais de comunicação não criptografados estão propensos a serem interceptados e adulterados.

Desativar a segurança de transporte expõe os dados a acesso não autorizado, possível roubo e adulteração.

Exemplo 1: A tarefa do Ansible de exemplo a seguir define um Banco de Dados do Azure para PostgreSQL com criptografia de transporte desabilitada.

- 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

Canais de comunicação não criptografados estão propensos a serem interceptados e adulterados.

Por padrão, a configuração https_only está definida como yes, impondo a transferência segura para uma conta de armazenamento do Azure. No entanto, essa configuração pode ser desabilitada explicitamente.

Desabilitar a transferência segura expõe os dados armazenados a acesso não autorizado, roubo em potencial e adulteração.

Exemplo 1: A tarefa do Ansible a seguir mostra uma conta de armazenamento que não impõe a transferência segura.

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

Por padrão, os clusters do Azure Kubernetes Service (AKS) criados pelo Ansible não enviam eventos de log para o Azure Monitor. Isso pode permitir que o comportamento mal-intencionado não seja detectado e, assim, impedir a análise forense no caso de uma violação.

Exemplo 1: A tarefa do Ansible de exemplo a seguir mostra um cluster do AKS que não envia eventos de log para o 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 falta de registros de auditoria limita a capacidade de detectar e responder a incidentes relacionados à segurança e impede a investigação 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

As chaves gerenciadas pelo cliente não são usadas para criptografar dados em repouso.

As chaves gerenciadas pelo cliente permitem que as organizações usem chaves criptográficas de sua escolha para criptografar dados. Isso dá às organizações melhor controle sobre os processos de criptografia.

Assim, as chaves gerenciadas pelo cliente geralmente fazem parte da solução para atender aos requisitos que incluem, mas não estão limitados a:
- Logs de auditoria para acesso a dados confidenciais
- Residência de dados
- Substituição, desabilitação ou destruição de chaves

As chaves gerenciadas pelo cliente não são usadas para criptografar dados em repouso.

As chaves gerenciadas pelo cliente permitem que as organizações usem chaves criptográficas de sua escolha para criptografar dados. Isso dá às organizações melhor controle sobre os processos de criptografia.

Assim, as chaves gerenciadas pelo cliente geralmente fazem parte da solução para atender aos requisitos que incluem, mas não estão limitados a:
- Logs de auditoria para acesso a dados confidenciais
- Residência de dados
- Substituição, desabilitação ou destruição de chaves

As chaves gerenciadas pelo cliente não são usadas para criptografar dados em repouso.

As chaves gerenciadas pelo cliente permitem que as organizações usem chaves criptográficas de sua escolha para criptografar dados. Isso dá às organizações melhor controle sobre os processos de criptografia.

Assim, as chaves gerenciadas pelo cliente geralmente fazem parte da solução para atender aos requisitos que incluem, mas não estão limitados a:
- Logs de auditoria para acesso a dados confidenciais
- Residência de dados
- Substituição, desabilitação ou destruição de chaves

As chaves gerenciadas pelo cliente não são usadas para criptografar dados em repouso.

As chaves gerenciadas pelo cliente permitem que as organizações usem chaves criptográficas de sua escolha para criptografar dados. Isso dá às organizações melhor controle sobre os processos de criptografia.

Assim, as chaves gerenciadas pelo cliente geralmente fazem parte da solução para atender aos requisitos que incluem, mas não estão limitados a:
- Logs de auditoria para acesso a dados confidenciais
- Residência de dados
- Substituição, desabilitação ou destruição de chaves

As chaves gerenciadas pelo cliente não são usadas para criptografar dados em repouso.

As chaves gerenciadas pelo cliente permitem que as organizações usem chaves criptográficas de sua escolha para criptografar dados. Isso dá às organizações melhor controle sobre os processos de criptografia.

Assim, as chaves gerenciadas pelo cliente geralmente fazem parte da solução para atender aos requisitos que incluem, mas não estão limitados a:
- Logs de auditoria para acesso a dados confidenciais
- Residência de dados
- Substituição, desabilitação ou destruição de chaves

Parâmetros confidenciais do modelo ARM do Azure, como senhas, geralmente usam os tipos securestring ou secureobject.

Para parâmetros que usam um tipo seguro, os valores dos parâmetros não são registrados ou armazenados no histórico de implantação.

No entanto, se um valor padrão com código rígido for configurado para um tipo seguro, esse valor padrão poderá ser lido por qualquer pessoa que possa acessar o modelo ou o histórico de implantação.

Segredos de código rígido podem comprometer a segurança de uma maneira que não é fácil de solucionar. Depois que o software estiver em produção, é necessária uma atualização para alterar o segredo comprometido.

No caso de um segredo usado para criptografar dados, as etapas de rotação de chave devem ser administradas para descriptografar e criptografar novamente todos os dados protegidos pela chave comprometida.

Exemplo 1: O modelo a seguir mostra um parâmetro com um tipo de segredo que tem um valor padrão de código rígido.

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

Todos os dados enviados por HTTP ficam visíveis e estão sujeitos a comprometimento.
Exemplo 1:

"supportsHttpsTrafficOnly": "false"

Um servidor da API Kubernetes acessível publicamente pode expor a organização a ataques.

Exemplo 1: O exemplo a seguir mostra um modelo que define um cluster de serviço Kubernetes que não restringe o intervalo de endereços IP que podem se conectar ao servidor de API.

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

As interfaces de depuração fornecem aos invasores informações que eles podem aproveitar para um ataque mais direcionado.

Exemplo 1: O modelo de exemplo a seguir define um Serviço de Aplicativo do Azure com depuração remota habilitada.

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

Por padrão, os contêineres de armazenamento de Blob do Azure evitam o acesso anônimo a seus Blobs.

As configurações de acesso insuficientes expõem os sistemas e ampliam a superfície de ataque de uma organização. Os recursos abertos ao acesso público podem vazar acidentalmente dados confidenciais.

Exemplo 1: O modelo de exemplo a seguir define um contêiner de Armazenamento de Blob do Azure com a propriedade publicAccess definida como Container . Isso permite acesso anônimo a todos os blobs e dados do Contêiner.

{
    "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'))]"
    ]
}