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.

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.

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'
        }
    }
}

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.

resource example 'Microsoft.Web/sites/config@2022-09-01' = {
    ...
    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.

param storageAccountName string
param containerName string

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