Mecanismos de autenticação fracos expõem as organizações a acesso não autorizado.

Os mecanismos de autenticação podem falhar por vários motivos, como:
- Senhas fracas
- Validação imprópria
- Gerenciamento de credenciais fraco

Mecanismos de autenticação fracos expõem as organizações a acesso não autorizado.

Os mecanismos de autenticação podem falhar por vários motivos, como:
- Senhas fracas
- Validação imprópria
- Gerenciamento de credenciais fraco

Mecanismos de autenticação fracos expõem as organizações a acesso não autorizado.

Os mecanismos de autenticação podem falhar por vários motivos, como:
- Senhas fracas
- Validação imprópria
- Gerenciamento de credenciais fraco

Mecanismos de autenticação fracos expõem as organizações a acesso não autorizado.

Os mecanismos de autenticação podem falhar por vários motivos, como:
- Senhas fracas
- Validação imprópria
- Gerenciamento de credenciais fraco

A autenticação é um aspecto essencial da segurança. A confiabilidade do processo de autenticação depende da segurança e da força das credenciais de login. As políticas de senha que garantem que os usuários criem senhas fortes são cruciais para a implantação de sites seguros. A força da senha é uma medida da eficácia que ela oferece em resistir a adivinhações e ataques de força bruta. Alguns parâmetros que ajudam a definir a força da senha incluem características de senha, como comprimento, complexidade e aleatoriedade da senha.

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

Os sistemas protegidos pela autenticação básica oferecem aos invasores um possível elo fraco. Os invasores podem comprometer as senhas (especialmente as fracas) por meio de força bruta, adivinhação ou engenharia social.

Exemplo 1: O exemplo a seguir mostra uma VM que permite a autenticação básica SSH.

{
    "resources": [
        {
            "type": "Microsoft.Compute/virtualMachines",
            "apiVersion": "2021-03-01",
            "name": "[variables('vmName')]",
            "location": "[parameters('location')]",
            ...
            "osProfile": {
                "computerName": "[variables('vmName')]",
                "adminUsername": "[parameters('adminUsername')]",
                "linuxConfiguration": {
                    "disablePasswordAuthentication": false
                }
            },
            ...
        }
    ]
}

As configurações de acesso insuficientes expõem os sistemas e ampliam a superfície de ataque de uma organização. Os serviços abertos à interação com a Internet estão sujeitos a varredura e investigação contínua por entidades mal-intencionadas.

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: O modelo de exemplo a seguir define um Azure Container Registry com acesso irrestrito à rede, habilitando a propriedade publicNetworkAccess e sem fazer restrições de IP.

{
    "name": "[variables('acrName')]",
    "type": "Microsoft.ContainerRegistry/registries",
    ...
    "properties": {
        "publicNetworkAccess": "Enabled",
        ..
}

Exemplo 2: O modelo de exemplo a seguir define um Azure Container Registry com acesso irrestrito à rede, especificando uma ampla lista de permissões para a propriedade networkRuleSet.

{
    "name": "[variables('acrName')]",
    "type": "Microsoft.ContainerRegistry/registries",
    ...
    "properties": {
        "publicNetworkAccess": "Enabled",
        "networkRuleSet":
        {
            "defaultAction": "Allow",
            "ipRules":[{
                "action": "Allow",
                "value": "*"
            }]
        }
        ...
}

O compartilhamento de recursos de origem cruzada, comumente referido como CORS, é uma tecnologia que permite a um domínio definir uma política para que seus recursos sejam acessados por uma página da web hospedada em um domínio diferente. Historicamente, os navegadores da web restringiram seus recursos de domínio de serem acessados por scripts carregados de um domínio diferente para obedecer à mesma política de origem.
CORS fornece um método para um domínio permitir outros domínios e que eles acessem seus recursos.

Tenha cuidado ao definir uma política CORS porque uma política excessivamente permissiva configurada no nível do servidor para um domínio ou um diretório em um domínio pode expor mais conteúdo para acesso entre domínios do que o pretendido. O CORS pode permitir que um aplicativo mal-intencionado se comunique com o aplicativo vítima de forma inadequada, o que pode levar à divulgação de informações, falsificação, roubo de dados, retransmissão ou outros ataques.

A implementação do CORS pode aumentar a superfície de ataque de um aplicativo e só deve ser usada quando necessário.

Exemplo 1: O modelo de exemplo a seguir define uma política CORS excessivamente permissiva para um aplicativo Web Azure SignalR.

{
    ...
    "type": "Microsoft.SignalRService/SignalR",
    ...
    "properties": {
    ...
        "cors": {
            "allowedOrigins": ["*"]
        },
    ...
}

Exemplo 2: O modelo de exemplo a seguir define uma política CORS excessivamente permissiva para um aplicativo Web do Azure.

{
    "apiVersion": "2020-12-01",
    "type": "Microsoft.Web/sites",
    ...
    "properties": {
        ...
        "siteConfig": {
            ...
            "cors": {
                "allowedOrigins": [
                    "*"
                ]
            },
    ...
}

Exemplo 3: O modelo de exemplo a seguir define uma política CORS excessivamente permissiva para uma conta do Azure Maps.

{
    "apiVersion": "2021-12-01-preview",
    "type": "Microsoft.Maps/accounts",
    ...
    "properties":{
        "cors":{
            "allowedOrigins": ["*"]
        }
    },
    ...
}

Exemplo 4: O modelo de exemplo a seguir define uma política CORS excessivamente permissiva para uma conta do Azure Cosmos DB.

{
    "type": "Microsoft.DocumentDB/databaseAccounts",
    ...
    "properties": {
        "cors": [{
            "allowedOrigins":"*"
        }],
    ...
}

Exemplo 5: O modelo de exemplo a seguir define uma política CORS excessivamente permissiva para um serviço de blob de armazenamento do Azure.

{
"type": "Microsoft.Storage/storageAccounts/blobServices",
    ...
    "properties": {
        "cors": {
            "corsRules": [
                {
                    "allowedOrigins":["*"],
                    ...
                }
            ]
        }
    }
    ...
}

As funções de proprietário personalizadas da assinatura do Azure fornecem acesso irrestrito a todos os recursos da assinatura, aumentando muito a exposição da organização a riscos e violando o princípio de privilégios mínimos.

Exemplo 1: O exemplo a seguir mostra uma definição de função de proprietário personalizada com todos os privilégios possíveis.

{
    "resources": [
        {
            "name": "roleDef",
            "type": "Microsoft.Authorization/roleDefinitions",
            "apiVersion": "2018-01-01-preview",
            "properties": {
                "roleName": "InfraAdmin",
                "description": "Infrastructure Admin",
                "permissions": [
                    {
                        "actions": [
                            "*"
                        ]
                    }
                ],
                ...
            }
        }
    ]
}

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

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: O modelo de exemplo a seguir define um Azure Cosmos DB com acesso irrestrito à rede. A propriedade publicNetworkAccess está definida como Enabled e o intervalo de endereços IP inclui todos os IPs.

{
    "type": "Microsoft.DocumentDB/databaseAccounts",
    "apiVersion": "2021-04-15",
    ...
    "properties": {
        ...
        "publicNetworkAccess": "Enabled",
        "ipRules":[{
                "ipAddressOrRange":  "0.0.0.0"
            }]
    ...
}