Partilhar via

Práticas recomendadas de segurança e conformidade de lotes

  • Artigo

Este artigo fornece orientações e práticas recomendadas para melhorar a segurança ao usar o Lote do Azure.

Por padrão, as contas do Lote do Azure têm um ponto de extremidade público e são acessíveis publicamente. Quando um pool de lotes do Azure é criado, o pool é provisionado em uma sub-rede especificada de uma rede virtual do Azure. As máquinas virtuais no pool de lotes são acessadas, por padrão, por meio de endereços IP públicos criados pelo lote. Os nós de computação em um pool podem se comunicar uns com os outros quando necessário, como para executar tarefas de várias instâncias, mas os nós em um pool não podem se comunicar com máquinas virtuais fora do pool.

Diagrama mostrando um ambiente de lote típico.

Muitos recursos estão disponíveis para ajudá-lo a criar uma implantação mais segura do Lote do Azure. Você pode restringir o acesso aos nós e reduzir a capacidade de descoberta dos nós da Internet provisionando o pool sem endereços IP públicos. Os nós de computação podem se comunicar com segurança com outras máquinas virtuais ou com uma rede local provisionando o pool em uma sub-rede de uma rede virtual do Azure. E pode ativar o acesso privado a partir de redes virtuais a partir de um serviço alimentado pelo Azure Private Link.

Diagrama mostrando um ambiente de lote mais seguro.

Configuração do pool

Os pools podem ser configurados em um dos dois modos de comunicação de nó, clássico ou simplificado. No modelo de comunicação de nó clássico, o serviço Batch inicia a comunicação com os nós de computação e os nós de computação também exigem comunicação com o Armazenamento do Azure. No modelo de comunicação de nó simplificado, os nós de computação iniciam a comunicação com o serviço em lote. Devido ao escopo reduzido de conexões de entrada/saída necessárias, e não exigindo acesso de saída do Armazenamento do Azure para operação de linha de base, a recomendação é usar o modelo de comunicação de nó simplificado. O modelo clássico de comunicação de nó será desativado em 31 de março de 2026.

Autenticação de conta em lote

O acesso à conta em lote suporta dois métodos de autenticação: Chave Compartilhada e ID do Microsoft Entra.

Recomendamos vivamente usar o Microsoft Entra ID para a autenticação da conta do Batch. Alguns recursos de lote exigem esse método de autenticação, incluindo muitos dos recursos relacionados à segurança discutidos aqui. O mecanismo de autenticação da API de serviço para uma conta Batch pode ser restrito apenas ao ID do Microsoft Entra usando a propriedade allowedAuthenticationModes . Quando essa propriedade é definida, as chamadas de API usando a autenticação de chave compartilhada são rejeitadas.

Modo de alocação do pool de contas em lote

Ao criar uma conta em lote, você pode escolher entre dois modos de alocação de pool:

  • Serviço em lote: a opção padrão, em que os recursos subjacentes do Conjunto de Escala de Máquina Virtual usados para alocar e gerenciar nós de pool são criados em assinaturas de propriedade de Lote e não são diretamente visíveis no portal do Azure. Somente os nós e pools de lotes são visíveis.
  • Assinatura de usuário: os recursos subjacentes do Conjunto de Escala de Máquina Virtual são criados na mesma assinatura que a conta de lote. Esses recursos são, portanto, visíveis na assinatura, além dos recursos de lote correspondentes.

Com o modo de assinatura de usuário, VMs em lote e outros recursos são criados diretamente em sua assinatura quando um pool é criado. O modo de assinatura de usuário é necessário se você quiser criar pools de lotes usando instâncias de VM reservadas do Azure, usar a Política do Azure em recursos do Conjunto de Escala de Máquina Virtual e/ou gerenciar a cota principal na assinatura (compartilhada em todas as contas de lote na assinatura). Para criar uma conta do Batch no modo de subscrição de utilizador, também tem de registar a sua subscrição no Azure Batch e associar a conta ao Azure Key Vault.

Restringir o acesso ao ponto de extremidade da rede

Pontos finais de rede em lote

Por padrão, os pontos de extremidade com endereços IP públicos são usados para se comunicar com contas de lote, pools de lotes e nós de pool.

API de conta em lote

Quando uma conta em lote é criada, um ponto de extremidade público é criado que é usado para invocar a maioria das operações para a conta usando uma API REST. O ponto de extremidade da conta tem uma URL base usando o formato https://{account-name}.{region-id}.batch.azure.com. O acesso à conta Batch é seguro, com a comunicação com o ponto de extremidade da conta sendo criptografada usando HTTPS e cada solicitação autenticada usando chave compartilhada ou autenticação Microsoft Entra.

Azure Resource Manager

Além das operações específicas de uma conta de lote, as operações de gerenciamento se aplicam a contas de lote único e múltiplo. Essas operações de gerenciamento são acessadas por meio do Azure Resource Manager.

As operações de gerenciamento em lote por meio do Azure Resource Manager são criptografadas usando HTTPS e cada solicitação é autenticada usando a autenticação do Microsoft Entra.

Nós de computação do pool de lotes

O serviço Batch se comunica com um agente de nó Batch que é executado em cada nó do pool. Por exemplo, o serviço instrui o agente do nó a executar uma tarefa, parar uma tarefa ou obter os arquivos para uma tarefa. A comunicação com o agente do nó é habilitada por um ou mais balanceadores de carga, cujo número depende do número de nós em um pool. O balanceador de carga encaminha a comunicação para o nó desejado, com cada nó sendo endereçado por um número de porta exclusivo. Por padrão, os balanceadores de carga têm endereços IP públicos associados a eles. Você também pode acessar remotamente os nós do pool via RDP ou SSH (esse acesso é habilitado por padrão, com comunicação via balanceadores de carga).

SO do nó de computação em lote

O Batch suporta os sistemas operacionais Linux e Windows. O Batch suporta Linux com um agente de nó alinhado para um subconjunto de distribuições do sistema operacional Linux. Recomenda-se que o sistema operacional seja mantido atualizado com os patches mais recentes fornecidos pelo editor do sistema operacional.

É recomendável habilitar a atualização automática do sistema operacional para pools de lotes, o que permite que a infraestrutura subjacente do Azure coordene atualizações em todo o pool. Esta opção pode ser configurada para não causar interrupções na execução da tarefa. A atualização automática do SO não suporta todos os sistemas operativos suportados pelo Batch. Para obter mais informações, consulte a Matriz de suporte de atualização automática do SO de conjuntos de escala de máquina virtual. Para sistemas operacionais Windows, verifique se você não está habilitando a propriedade virtualMachineConfiguration.windowsConfiguration.enableAutomaticUpdates ao usar a atualização automática do sistema operacional no pool de lotes.

O suporte em lote para imagens e agentes de nó é eliminado gradualmente ao longo do tempo, normalmente alinhado com os cronogramas de suporte do editor. Recomenda-se evitar o uso de imagens com datas de fim de vida iminente (EOL) ou imagens que já passaram da data EOL. É sua responsabilidade atualizar periodicamente sua exibição das datas EOL pertinentes aos seus pools e migrar suas cargas de trabalho antes que a data EOL ocorra. Se você estiver usando uma imagem personalizada com um agente de nó especificado, certifique-se de seguir as datas de fim de vida útil do suporte em lote para a imagem para a qual sua imagem personalizada é derivada ou alinhada. Uma imagem sem uma data especificada batchSupportEndOfLife indica que essa data ainda não foi determinada pelo serviço Batch. A ausência de uma data não indica que a respetiva imagem será suportada indefinidamente. Uma data EOL pode ser adicionada ou atualizada no futuro a qualquer momento. As datas EOL podem ser descobertas por meio da API, PowerShell ListSupportedImages ou CLI do Azure.

Segurança da camada de transporte do sistema operacional Windows (TLS)

O agente do nó Batch não modifica os padrões no nível do sistema operacional para versões SSL/TLS ou pedidos de pacotes de codificação. No Windows, as versões SSL/TLS e a ordem do conjunto de codificação são controladas no nível do sistema operacional e, portanto, o agente do nó em lote adota as configurações definidas pela imagem usada por cada nó de computação. Embora o agente do nó Batch tente utilizar as configurações mais seguras disponíveis quando possível, ele ainda pode ser limitado pelas configurações no nível do sistema operacional. Recomendamos que você revise os padrões de nível do sistema operacional e os defina adequadamente para o modo mais seguro que é compatível com seu fluxo de trabalho e requisitos organizacionais. Para obter mais informações, visite Manage TLS for cipher suite order enforcement and TLS registry settings for SSL/TLS version control for Schannel SSP. Observe que algumas alterações de configuração exigem uma reinicialização para entrar em vigor. Recomenda-se a utilização de um sistema operacional mais recente com padrões de segurança modernos ou uma imagem personalizada com configurações modificadas em vez da aplicação de tais configurações com uma tarefa de início em lote.

Restringindo o acesso a pontos de extremidade em lote

Vários recursos estão disponíveis para limitar o acesso aos vários pontos de extremidade Batch, especialmente quando a solução usa uma rede virtual.

Utilizar pontos finais privados

O Azure Private Link permite o acesso aos Serviços PaaS do Azure e aos serviços hospedados pelo cliente por meio de um ponto de extremidade privado em sua rede virtual. Você pode usar o Private Link para restringir o acesso a uma conta Batch de dentro da rede virtual ou de qualquer rede virtual emparelhada. Os recursos mapeados para Link Privado também podem ser acessados localmente por meio de emparelhamento privado por meio de VPN ou Rota Expressa do Azure.

Para usar pontos de extremidade privados, uma conta em lote precisa ser configurada adequadamente quando criada; A configuração de acesso à rede pública deve ser desativada. Uma vez criados, os pontos de extremidade privados podem ser criados e associados à conta Batch. Para obter mais informações, consulte Usar pontos de extremidade privados com contas do Lote do Azure.

Criar pools em redes virtuais

Os nós de computação em um pool de lotes podem se comunicar uns com os outros, como executar tarefas de várias instâncias, sem exigir uma rede virtual (VNET). No entanto, por padrão, os nós em um pool não podem se comunicar com máquinas virtuais que estão fora do pool em uma rede virtual e têm endereços IP privados, como servidores de licença ou servidores de arquivos.

Para permitir que os nós de computação se comuniquem com segurança com outras máquinas virtuais ou com uma rede local, você pode configurar um pool para estar em uma sub-rede de uma VNET do Azure.

Quando os pools têm pontos de extremidade IP públicos, a sub-rede deve permitir a comunicação de entrada do serviço em lote para poder agendar tarefas e executar outras operações nos nós de computação, e a comunicação de saída para se comunicar com o Armazenamento do Azure ou outros recursos, conforme necessário para sua carga de trabalho. Para pools na configuração da Máquina Virtual, o Batch adiciona NSGs (grupos de segurança de rede) no nível da interface de rede anexada aos nós de computação. Estes NSG têm regras que permitem:

  • Tráfego TCP de entrada de endereços IP do serviço de lote
  • Tráfego TCP de entrada para acesso remoto
  • Tráfego de saída em qualquer porta para a rede virtual (pode ser alterado de acordo com as regras NSG no nível da sub-rede)
  • Tráfego de saída em qualquer porta para a Internet (pode ser alterado de acordo com as regras NSG de nível de sub-rede)

Não é necessário especificar NSGs no nível de sub-rede de rede virtual, porque o Batch configura seus próprios NSGs. Se você tiver um NSG associado à sub-rede onde os nós de computação em lote são implantados ou se quiser aplicar regras NSG personalizadas para substituir os padrões aplicados, deverá configurar esse NSG com pelo menos as regras de segurança de entrada e saída para permitir a comunicação do serviço de lote com os nós do pool e a comunicação do nó do pool com o Armazenamento do Azure.

Para obter mais informações, consulte Criar um pool de lotes do Azure em uma rede virtual.

Criar pools com endereços IP públicos estáticos

Por padrão, os endereços IP públicos associados a pools são dinâmicos; eles são criados quando um pool é criado e os endereços IP podem ser adicionados ou removidos quando um pool é redimensionado. Quando os aplicativos de tarefa em execução em nós de pool precisam acessar serviços externos, o acesso a esses serviços pode precisar ser restrito a IPs específicos. Nesse caso, ter endereços IP dinâmicos não será gerenciável.

Você pode criar recursos de endereço IP público estático na mesma assinatura que a conta em lote antes da criação do pool. Em seguida, você pode especificar esses endereços ao criar seu pool.

Para obter mais informações, consulte Criar um pool de lotes do Azure com endereços IP públicos especificados.

Criar pools sem endereços IP públicos

Por padrão, todos os nós de computação em um pool de configuração de máquina virtual do Azure Batch recebem um ou mais endereços IP públicos. Esses pontos de extremidade são usados pelo serviço Batch para agendar tarefas e para comunicação com nós de computação, incluindo acesso de saída à Internet.

Para restringir o acesso a estes nós e reduzir a deteção dos mesmos a partir da Internet, pode aprovisionar o conjunto sem endereços IP públicos.

Para obter mais informações, consulte Criar um pool sem endereços IP públicos.

Limitar o acesso remoto aos nós do pool

Por padrão, o Batch permite que um usuário de nó com conectividade de rede se conecte externamente a um nó de computação em um pool de Batch usando RDP ou SSH.

Para limitar o acesso remoto aos nós, use um dos seguintes métodos:

  • Configure o PoolEndpointConfiguration para negar acesso. O NSG (grupo de segurança de rede) apropriado será associado ao pool.
  • Crie seu pool sem endereços IP públicos. Por padrão, esses pools não podem ser acessados fora da rede virtual.
  • Associe um NSG à VNet para negar acesso às portas RDP ou SSH.
  • Não crie nenhum usuário no nó. Sem usuários de nó, o acesso remoto não será possível.

Encriptar dados

Criptografar dados em trânsito

Toda a comunicação com o ponto de extremidade da conta em lote (ou por meio do Gerenciador de Recursos do Azure) deve usar HTTPS. Você deve usar https:// as URLs de conta de lote especificadas em APIs ao se conectar ao serviço de lote.

Os clientes que se comunicam com o serviço em lote devem ser configurados para usar o Transport Layer Security (TLS) 1.2.

Criptografar dados em lote em repouso

Algumas das informações especificadas em APIs de lote, como certificados de conta, metadados de tarefas e tarefas e linhas de comando de tarefas, são criptografadas automaticamente quando armazenadas pelo serviço em lote. Por padrão, esses dados são criptografados usando chaves gerenciadas pela plataforma do Azure Batch exclusivas para cada conta do Lote.

Você também pode criptografar esses dados usando chaves gerenciadas pelo cliente. O Azure Key Vault é usado para gerar e armazenar a chave, com o identificador de chave registrado com sua conta Batch.

Criptografar discos de nó de computação

Os nós de computação em lote têm dois discos por padrão: um disco do sistema operacional e o SSD temporário local. Os arquivos e diretórios gerenciados pelo Batch estão localizados no SSD temporário, que é o local padrão para arquivos como arquivos de saída de tarefas. Os aplicativos de tarefas em lote podem usar o local padrão no SSD ou no disco do sistema operacional.

Para segurança extra, criptografe esses discos usando um destes recursos de criptografia de disco do Azure:

Aceda com segurança a serviços a partir de nós de computação

Use identidades gerenciadas do Pool com as permissões de acesso apropriadas configuradas para a identidade gerenciada atribuída pelo usuário para acessar os serviços do Azure que oferecem suporte à identidade gerenciada, incluindo o Cofre da Chave do Azure. Se você precisar provisionar certificados em nós de lote, utilize a extensão de VM do Azure Key Vault disponível com a Identidade Gerenciada do pool para instalar e gerenciar certificados em seu pool de lotes. Para obter mais informações sobre como implantar certificados do Cofre de Chaves do Azure com Identidade Gerenciada em pools de lotes, consulte Habilitar a rotação automática de certificados em um pool de lotes.

Governação e conformidade

Conformidade

Para ajudar os clientes a cumprir as suas próprias obrigações de conformidade em setores e mercados regulamentados em todo o mundo, o Azure mantém um vasto portefólio de ofertas de conformidade.

Essas ofertas são baseadas em vários tipos de garantias, incluindo certificações formais, atestados, validações, autorizações e avaliações produzidas por empresas de auditoria terceirizadas independentes, bem como alterações contratuais, autoavaliações e documentos de orientação ao cliente produzidos pela Microsoft. Analise a visão geral abrangente das ofertas de conformidade para determinar quais podem ser relevantes para suas soluções em lote.

Azure Policy

A Política do Azure ajuda a impor padrões organizacionais e a avaliar a conformidade em escala. Casos comuns de utilização do Azure Policy incluem a implementação de governação para consistência de recursos, conformidade regulamentar, segurança, custos e gestão.

Dependendo do seu modo de alocação de pool e dos recursos aos quais uma política deve ser aplicada, use a Política do Azure com Lote de uma das seguintes maneiras:

  • Diretamente, usando o recurso Microsoft.Batch/batchAccounts. Um subconjunto das propriedades de uma conta Batch pode ser usado. Por exemplo, sua política pode incluir regiões de conta de lote válidas, modo de alocação de pool permitido e se uma rede pública está habilitada para contas.
  • Indiretamente, usando o recurso Microsoft.Compute/virtualMachineScaleSets. As contas em lote com o modo de alocação do pool de assinaturas do usuário podem ter a política definida nos recursos do Conjunto de Escala da Máquina Virtual criados na assinatura da conta em lote. Por exemplo, tamanhos de VM permitidos e garantir que determinadas extensões sejam executadas em cada nó do pool.

Próximos passos