Práticas recomendadas de segurança e conformidade de processos em lote

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

Por padrão, as contas do Azure Batch 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 Batch pool são acessadas, por padrão, por meio de endereços IP públicos criados pelo Batch. 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.

Muitas funcionalidades estão disponíveis para ajudá-lo a criar uma implementação do Azure Batch mais segura. 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.

Práticas recomendadas gerais relacionadas à segurança

Configuração do pool

Os pools podem ser configurados num de 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 Batch. Recomenda-se usar o modelo de comunicação de nó simplificado, devido ao escopo reduzido das conexões de entrada e saída necessárias e sem exigir acesso de saída ao Armazenamento do Azure para a operação de linha de base. O modelo clássico de comunicação de nó será desativado em 31 de março de 2026.

Os pools também devem ser configurados com configurações de segurança aprimoradas, incluindo Inicialização Confiável (requer imagens de VM Gen2 e um tamanho de VM compatível), permitindo inicialização segura, vTPM e criptografia no host (requer um tamanho de VM compatível).

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.

É altamente recomendável usar o Microsoft Entra ID para autenticação de conta em lote. 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 limitado exclusivamente ao uso do Microsoft Entra ID 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 Virtual Machine Scale Set usados para alocar e gerenciar nós de pool são criados em assinaturas de propriedade do Batch, e não são visíveis diretamente no portal Azure. Só os pools de lotes e nós são visíveis.
• Assinatura do utilizador: os recursos subjacentes do Conjunto de Dimensionamento de Máquinas Virtuais são criados na mesma assinatura que a conta Batch. 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, deve também registar a sua subscrição no Azure Batch e associar a conta a um 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 contas em lote

Quando uma conta Batch é criada, é criado um ponto de extremidade público 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 para o endpoint da conta criptografada usando HTTPS, e cada solicitação é autenticada usando chave partilhada 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, e cada nó é identificado por um número de porta único. Por padrão, os balanceadores de carga têm endereços IP públicos associados a eles. Você também pode acessar remotamente nós de pool via RDP ou SSH, consulte Configurar acesso remoto a nós de computação em um pool de Lotes do Azure.

SO do nó de computação em lote

O Batch suporta os sistemas operacionais Linux e Windows. O Batch oferece suporte ao Linux com um agente de nodo otimizado para um subconjunto de distribuições Linux. Recomenda-se que o sistema operativo se mantenha up-toatualizado com os patches mais recentes fornecidos pelo publicador do sistema operativo.

É 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 mais informações, consulte a Matriz de Suporte de Atualização Automática do SO para Conjuntos de Escala de Máquinas Virtuais. 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ó é descontinuado ao longo do tempo, normalmente alinhado com os prazos 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 estiver a usar uma imagem personalizada com um agente de nó especificado, assegure-se de seguir as datas de fim de vida útil do suporte Batch para a imagem da qual a sua imagem personalizada é derivada ou com a qual está 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 via ListSupportedImages API, PowerShell ou Azure CLI.

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 Gerir TLS para aplicação da ordem de suites de cifras e definições de registo TLS para controlo das versões SSL/TLS para o 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 endpoints Batch

Estão disponíveis várias capacidades para limitar o acesso aos diferentes endpoints Batch, especialmente quando a solução utiliza uma rede virtual.

Utilizar pontos finais privados

O Azure Private Link permite o acesso aos Serviços PaaS do Azure e aos serviços do cliente ou de parceiros hospedados no Azure por meio de um ponto de extremidade privado na 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 Batch 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 Azure Batch.

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 Batch, possibilitando assim o agendamento de tarefas e a execução de outras operações nos nós de computação, bem como a comunicação de saída para se conectar com o Armazenamento do Azure ou outros recursos, conforme necessário para a sua carga de trabalho. Para pools na configuração da Máquina Virtual, o Batch adiciona grupos de segurança de rede (NSGs) ao 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 proveniente dos endereços IP do serviço Batch
• 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 ao nível da 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 subscrição que a conta do Batch 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

Para pools criados com uma versão de API anterior ao 2024-07-01, o Batch, por padrão, permite que um utilizador de nó com conectividade de rede se conecte externamente a um nó de computação num pool Batch usando RDP ou SSH.

Para limitar o acesso remoto, crie seus pools usando uma versão 2024-07-01 da API ou posterior.

Para limitar o acesso remoto a nós em pools criados com a versão da API anterior a 2024-07-01, 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 utilizador no nó. Sem utilizadores de nós da rede, o acesso remoto não será possível.

Encriptar dados

Criptografar dados em trânsito

Toda a comunicação com o ponto final da conta Batch (ou por meio do Gerenciador de Recursos do Azure) deve usar HTTPS. Você deve usar https:// nos URLs de Conta Batch especificados nas APIs ao se conectar ao serviço Batch.

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, os dados são criptografados usando chaves geridas pela plataforma Azure Batch, exclusivas para cada conta Batch.

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.

Encriptar discos de nós 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:

• Criptografia de disco gerenciado em repouso com chaves gerenciadas pela plataforma
• Criptografia no host usando uma chave gerenciada pela plataforma
• Azure Disk Encryption

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 precisar provisionar certificados nos nós do Azure Batch, utilize a extensão de VM do Azure Key Vault disponível com a Managed Identity do pool para instalar e gerir certificados no seu pool Batch. 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.

Governança 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.

Política do Azure

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, a sua política pode incluir regiões de conta Batch válidas, o modo de alocação de pools 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

• Analise a linha de base de segurança do Azure para Batch.
• Leia mais práticas recomendadas para o Azure Batch.