Editar

Partilhar via

Considerações de segurança para aplicações IaaS altamente confidenciais no Azure

Azure Disk Encryption
Azure Firewall
Azure Key Vault
Microsoft Defender for Cloud
Azure Virtual Network

Há muitas considerações de segurança para implantar aplicativos de infraestrutura como serviço (IaaS) no Azure. Este artigo baseia-se em arquiteturas de referência para cargas de trabalho baseadas em máquinas virtuais e infraestruturas de rede híbridas para se concentrar na segurança para cargas de trabalho IaaS altamente sensíveis no Azure, com base nos fundamentos de segurança do Azure.

Consulte também Visão geral da segurança de máquinas virtuais do Azure e Práticas recomendadas de segurança para cargas de trabalho IaaS no Azure.

VMs do Azure

A plataforma de computação do Azure é baseada na virtualização de máquinas. Um hipervisor é executado no hardware físico de cada nó do Azure ou ponto de extremidade de rede e cria um número variável de máquinas virtuais (VMs) Hyper-V convidadas no nó. Todo o código de usuário é executado nas VMs. Para obter instruções básicas de implantação da VM do Azure, consulte Executar uma VM Linux no Azure ou Executar uma VM do Windows no Azure. A maioria dos processos de implantação são os mesmos para os dois sistemas operacionais (SOs), mas ferramentas específicas do sistema operacional, como criptografia de disco, podem ser diferentes.

Você pode usar o Microsoft Defender for Cloud para gerenciamento de patches de VM e implantar e monitorar ferramentas antimalware. Como alternativa, você pode gerenciar suas próprias ferramentas antimalware e de patches ou de terceiros, o que é comum ao estender ou migrar infraestruturas existentes para o Azure.

A Microsoft fornece proteção básica de negação de serviço distribuída (DDoS) como parte da plataforma Azure. Os aplicativos que têm pontos de extremidade públicos podem usar a Proteção contra DDoS Padrão do Azure para proteção adicional. No entanto, cargas de trabalho altamente confidenciais geralmente não têm pontos de extremidade públicos e só podem ser acessadas de locais específicos por meio de uma rede virtual privada (VPN) ou linha alugada.

Arquiteturas de N camadas

Muitos aplicativos IaaS consistem em várias camadas, como uma camada da Web, uma camada de negócios e uma camada de dados, que são hospedadas em várias VMs. Os principais aspetos da implantação de arquiteturas de aplicativos de n camadas em VMs do Azure incluem:

  • Alta disponibilidade (HA). Os aplicativos HA devem estar disponíveis mais de 99,9% do tempo. Colocar VMs em camadas em diferentes zonas de disponibilidade do Azure garante HA, porque as zonas de disponibilidade abrangem um ou mais datacenters, fornecendo resiliência por meio da resistência a falhas de datacenter. As regiões que não oferecem suporte a zonas de disponibilidade podem usar conjuntos de disponibilidade, que distribuem VMs em vários nós de hardware isolados.
  • Balanceamento de carga. Os balanceadores de carga distribuem o tráfego entre VMs, para equilibrar a carga e para resiliência quando uma VM falha. Você não precisará de balanceadores de carga se o aplicativo gerenciar o balanceamento de carga e as VMs individuais forem conhecidas pelo chamador.
  • Redes virtuais. As redes virtuais e as sub-redes segmentam a sua rede, permitindo uma gestão de segurança mais fácil e um encaminhamento avançado.
  • Sistema de Nomes de Domínio (DNS). O DNS do Azure fornece um serviço DNS altamente disponível e seguro. Uma zona privada no DNS do Azure permite que você use domínios personalizados dentro de suas redes virtuais.

Cópia de segurança e restauro

Para proteger contra erro humano, exclusão de dados mal-intencionados e ransomware, você deve fazer backup de pelo menos suas VMs de camada de dados. O Backup do Azure pode fazer backup e restaurar VMs criptografadas se puder acessar as chaves de criptografia no Cofre de Chaves do Azure.

Para as camadas da Web e de negócios, você pode usar regras de dimensionamento automático de conjunto de máquina virtual para destruir automaticamente VMs comprometidas e implantar novas instâncias de VM a partir de uma imagem base.

Isolamento de computação

Em cada nó do Azure ou ponto de extremidade de rede, o hipervisor e um sistema operacional raiz especial garantem que as VMs convidadas não possam acessar o servidor host físico e que o código do usuário seja executado somente em VMs convidadas. Esse isolamento impede que os usuários obtenham acesso bruto de leitura, gravação ou execução ao sistema e reduz o risco de compartilhamento de recursos. O Azure protege contra todos os ataques de canal lateral conhecidos e vizinhos barulhentos através do hipervisor e de um algoritmo avançado de posicionamento de VM. Para obter mais informações, consulte Isolamento de computação.

Para cargas de trabalho altamente confidenciais, você pode adicionar proteção adicional contra ataques de canal lateral com VMs isoladas ou hosts dedicados.

VMs isoladas

VMs isoladas são grandes tamanhos de VM que são isolados para um tipo de hardware específico e dedicados a um único cliente. Usar um tamanho de VM isolado garante que sua VM seja a única em execução em uma instância de servidor específica. Você pode subdividir ainda mais os recursos de VMs isoladas usando o suporte do Azure para máquinas virtuais aninhadas.

O tamanho mínimo de uma VM isolada é de 64 núcleos de CPU virtual e 256 GiB de memória. Essas VMs são muito maiores do que a maioria dos aplicativos de n camadas exigem e podem criar uma grande sobrecarga de custos. Para reduzir a sobrecarga, você pode executar várias camadas de aplicativo em uma única VM com virtualização aninhada ou em diferentes processos ou contêineres. Você ainda precisa implantar VMs diferentes em zonas de disponibilidade para resiliência e executar dispositivos de zona desmilitarizada (DMZ) em VMs separadas. A combinação de vários aplicativos em uma infraestrutura por motivos econômicos também pode entrar em conflito com as políticas de segregação de aplicativos organizacionais.

À medida que os recursos da região do Azure se expandem ao longo do tempo, o Azure também pode remover garantias de isolamento de determinados tamanhos de VM, com aviso prévio de um ano.

Azure Dedicated Hosts

O Host Dedicado do Azure é a solução de isolamento de computação preferida para cargas de trabalho altamente confidenciais. Um host dedicado é um servidor físico dedicado a um cliente para hospedar várias VMs. Além de isolar VMs, os hosts dedicados permitem controlar a manutenção e o posicionamento das VMs para evitar vizinhos barulhentos.

Anfitriões dedicados

Os hosts dedicados têm o mesmo tamanho mínimo e muitas das mesmas considerações de dimensionamento que as VMs isoladas. No entanto, um host dedicado pode hospedar VMs localizadas em diferentes redes virtuais, para satisfazer as políticas de segregação de aplicativos. Você ainda deve executar VMs DMZ em um host diferente, para evitar qualquer ataque de canal lateral de uma VM comprometida na DMZ.

Encriptação

A criptografia de dados é um componente importante da proteção de cargas de trabalho. A criptografia codifica informações para que apenas recetores autorizados possam decodificá-las usando uma chave ou certificado. A criptografia inclui criptografia de disco, para criptografia de dados em repouso, e TLS (Transport Level Security), para criptografia em trânsito em redes.

Azure Key Vault

Você pode proteger chaves de criptografia e certificados armazenando-os no Azure Key Vault, uma solução HSM (Hardware Security Module) na nuvem validada para FIPS (Federal Information Processing Standards) 140-2 Nível 2. Para obter as práticas recomendadas para permitir que apenas aplicativos e usuários autorizados acessem o Cofre de Chaves, consulte Acesso seguro a um cofre de chaves.

Para proteger as chaves no Cofre da Chave, você pode ativar a exclusão suave, o que garante que as chaves excluídas sejam recuperáveis. Para obter proteção adicional, você pode fazer backup de chaves individuais em um arquivo criptografado que pode ser usado para restaurar as chaves, potencialmente para outra região do Azure na mesma geografia.

Ao hospedar o SQL Server em uma VM, você pode usar o SQL Server Connector for Microsoft Azure Key Vault para obter chaves para criptografia de dados transparente (TDE), criptografia de nível de coluna (CLE) e criptografia de backup. Para obter detalhes, consulte Configurar a integração do Cofre de Chaves do Azure para SQL Server em máquinas virtuais do Azure.

Azure Disk Encryption

A Criptografia de Disco do Azure usa um protetor de chave externa do BitLocker para fornecer criptografia de volume para o sistema operacional e os discos de dados das VMs do Azure e pode ser integrada ao Cofre da Chave do Azure para ajudá-lo a controlar e gerenciar chaves e segredos de criptografia de disco. Cada VM gera suas próprias chaves de criptografia e as armazena no Cofre de Chaves do Azure. Para configurar o Cofre da Chave do Azure para habilitar a Criptografia de Disco do Azure, consulte Criar e configurar um cofre de chaves para a Criptografia de Disco do Azure.

Para cargas de trabalho altamente confidenciais, você também deve usar uma chave de criptografia de chave (KEK) para uma camada adicional de segurança. Quando você especifica um KEK, o Azure Disk Encryption usa essa chave para encapsular os segredos de criptografia antes de gravar no Cofre da Chave. Você pode gerar um KEK no Cofre de Chaves do Azure, mas um método mais seguro é gerar uma chave em seu HSM local e importá-la para o Cofre de Chaves do Azure. Este cenário costuma chamar-se Bring Your Own Key ou BYOK. Como as chaves importadas não podem sair do limite do HSM, gerar a chave no HSM garante que você tenha controle total das chaves de criptografia.

Criptografia protegida por HSM

Para obter mais informações sobre chaves protegidas por HSM, consulte Como gerar e transferir chaves protegidas por HSM para o Cofre de Chaves do Azure.

Encriptação de tráfego de rede

Protocolos de rede como HTTPS criptografam dados em trânsito com certificados. O tráfego de cliente para aplicativo geralmente usa um certificado de uma autoridade de certificação (CA) confiável. Os aplicativos internos podem usar um certificado de uma CA interna ou pública, como DigiCert ou GlobalSign. A comunicação de nível a nível normalmente usa um certificado emitido por uma autoridade de certificação interna ou um certificado autoassinado. O Azure Key Vault pode acomodar qualquer um desses tipos de certificado. Para obter mais informações sobre como criar diferentes tipos de certificado, consulte Métodos de criação de certificados.

O Azure Key Vault pode atuar como uma CA de certificado autoassinada para tráfego de camada a camada. A extensão de VM do Cofre da Chave fornece monitoramento e atualização automática de certificados especificados em VMs, com ou sem a chave privada, dependendo do caso de uso. Para usar a extensão de máquina virtual do Cofre da Chave, consulte Extensão de máquina virtual do Cofre da Chave para Linux ou Extensão da máquina virtual do Cofre da Chave para Windows.

O Cofre de Chaves também pode armazenar chaves para protocolos de rede que não usam certificados. Cargas de trabalho personalizadas podem exigir a criação de scripts de uma extensão de script personalizada que recupere uma chave do Cofre da Chave e a armazene para uso dos aplicativos. Os aplicativos também podem usar a identidade gerenciada de uma VM para recuperar segredos diretamente do Cofre da Chave.

Segurança da rede

Os NSGs (grupos de segurança de rede) filtram o tráfego entre recursos nas redes virtuais do Azure. As regras de segurança do NSG permitem ou negam tráfego de rede de ou para recursos do Azure com base em endereços IP e portas. Por padrão, os NSGs bloqueiam o tráfego de entrada da Internet, mas permitem conexões de saída de VMs para a Internet. Para evitar tráfego de saída acidental, adicione uma regra personalizada com a menor prioridade possível, 4096, para bloquear todo o tráfego de entrada e saída. Em seguida, você pode adicionar regras de prioridade mais alta para permitir tráfego específico.

Os NSGs criam registros de fluxo para conexões existentes e permitem ou negam a comunicação com base no estado de conexão do registro de fluxo. O registro de fluxo permite que um NSG seja stateful. Por exemplo, se você especificar uma regra de segurança de saída para qualquer endereço pela porta 443, não será necessário especificar também uma regra de segurança de entrada para a resposta. Você só precisa especificar uma regra de segurança de entrada se a comunicação for iniciada externamente.

A maioria dos serviços do Azure permite que você use uma marca de serviço de rede virtual em vez de um NSG. Uma marca de serviço representa um grupo de prefixos de endereço IP de um serviço do Azure e ajuda a minimizar a complexidade de atualizações frequentes de regras de segurança de rede. Uma marca de serviço do Cofre de Chaves do Azure pode permitir que uma VM recupere certificados, chaves e segredos do Cofre de Chaves do Azure.

Outra maneira de controlar a segurança da rede é através do roteamento de tráfego de rede virtual e túnel forçado. O Azure cria automaticamente as rotas do sistema e atribui-as a cada sub-rede numa rede virtual. Não é possível criar ou remover rotas do sistema, mas é possível substituir algumas rotas do sistema por rotas personalizadas. O roteamento personalizado permite rotear o tráfego através de um dispositivo virtual de rede (NVA), como um firewall ou proxy, ou descartar o tráfego indesejado, o que tem um efeito semelhante ao bloqueio do tráfego com um NSG.

Você pode usar NVAs como o Firewall do Azure para permitir, bloquear e inspecionar o tráfego de rede. O Firewall do Azure é um serviço de firewall de plataforma gerenciado e altamente disponível. Também pode implementar NVAs de terceiros a partir do Azure Marketplace. Para tornar esses NVAs altamente disponíveis, consulte Implantar dispositivos virtuais de rede altamente disponíveis.

Grupos de segurança de aplicação

Para filtrar o tráfego entre as camadas de aplicativos em uma rede virtual, use os grupos de segurança de aplicativos (ASGs). Os ASGs permitem configurar a segurança de rede como uma extensão da estrutura de um aplicativo, permitindo agrupar VMs e definir políticas de segurança de rede com base nos grupos. Você pode reutilizar sua política de segurança em escala sem manter manualmente endereços IP explícitos.

Grupos de segurança de aplicação

Como os ASGs são aplicados a uma interface de rede em vez de uma sub-rede, eles permitem a microssegmentação. Você pode controlar rigorosamente quais VMs podem conversar entre si, até mesmo bloqueando o tráfego entre VMs na mesma camada e facilitando a quarentena de uma VM removendo ASGs dessa VM.

Redes híbridas

As arquiteturas híbridas conectam redes locais com nuvens públicas como o Azure. Há várias maneiras de conectar redes locais a aplicativos em execução no Azure:

  • Ponto final público através da Internet. Você pode confiar na identidade, na segurança de nível de transporte (HTTPS) e no gateway do aplicativo para proteger o aplicativo, potencialmente em combinação com um firewall. No entanto, para cargas de trabalho altamente confidenciais, a exposição de um ponto de extremidade público pela Internet não é recomendada.
  • Azure ou gateway de VPN de terceiros. Você pode conectar uma rede local ao Azure usando um gateway de VPN do Azure. O tráfego ainda viaja pela internet, mas por um túnel criptografado que usa TLS. Você também pode executar um gateway de terceiros em uma VM, se tiver requisitos específicos não suportados pelo gateway de VPN do Azure.
  • Rota Expressa. As ligações do ExpressRoute utilizam uma ligação privada dedicada através de um fornecedor de conectividade de terceiros. A conexão privada estende sua rede local para o Azure e fornece escalabilidade e um SLA (contrato de nível de serviço) confiável.
    • ExpressRoute com failover de VPN. Essa opção usa a Rota Expressa em condições normais, mas faz failover para uma conexão VPN se houver uma perda de conectividade no circuito da Rota Expressa, proporcionando maior disponibilidade.
    • VPN através da Rota Expressa. Esta opção é a melhor para cargas de trabalho altamente sensíveis. A Rota Expressa fornece um circuito privado com escalabilidade e confiabilidade, e a VPN fornece uma camada adicional de proteção que encerra a conexão criptografada em uma rede virtual específica do Azure.

Para obter mais orientações sobre como escolher entre diferentes tipos de conectividade híbrida, consulte Escolher uma solução para conectar uma rede local ao Azure.

Implantar uma DMZ

A conexão de ambientes locais e do Azure dá aos usuários locais acesso aos aplicativos do Azure. Uma rede de perímetro ou zona desmilitarizada (DMZ) fornece proteção adicional para cargas de trabalho altamente sensíveis.

Uma arquitetura como a da DMZ de rede entre o Azure e um datacenter local implanta todos os serviços DMZ e de aplicativos na mesma rede virtual, com regras NSG e rotas definidas pelo usuário para isolar a DMZ e as sub-redes do aplicativo. Essa arquitetura pode disponibilizar a sub-rede de gerenciamento via Internet pública, para gerenciar aplicativos mesmo que o gateway local não esteja disponível. No entanto, para cargas de trabalho altamente confidenciais, você só deve permitir ignorar o gateway em um cenário de quebra de vidro. Uma solução melhor é usar o Azure Bastion, que permite o acesso diretamente do portal do Azure enquanto limita a exposição de endereços IP públicos.

Você também pode usar o acesso a VM Just-In-Time (JIT) para gerenciamento remoto, limitando a exposição de endereços IP públicos. Com o acesso à VM JIT, um NSG bloqueia portas de gerenciamento remoto como protocolo de área de trabalho remota (RDP) e shell seguro (SSH) por padrão. Mediante solicitação, o acesso à VM JIT habilita a porta apenas para uma janela de tempo especificada e, potencialmente, para um endereço IP ou intervalo específico. O acesso JIT também funciona para VMs que têm apenas endereços IP privados. Você pode usar o Azure Bastion para bloquear o tráfego para uma VM até que o acesso à VM JIT esteja habilitado.

Para implantar mais aplicativos, você pode usar uma topologia de rede hub-spoke no Azure, com a DMZ na rede virtual do hub e os aplicativos em redes virtuais spoke. A rede virtual do hub pode conter uma VPN e/ou gateway de Rota Expressa, NVA de firewall, hosts de gerenciamento, infraestrutura de identidade e outros serviços compartilhados. As redes virtuais spoke são conectadas ao hub com emparelhamento de rede virtual. Uma rede virtual do Azure não permite roteamento transitivo pelo hub de um falado para outro. O tráfego Spoke-to-spoke só é possível através dos dispositivos de firewall no hub. Essa arquitetura isola efetivamente os aplicativos uns dos outros.

Implementação em várias regiões

A continuidade de negócios e a recuperação de desastres podem exigir a implantação de seu aplicativo em várias regiões do Azure, o que pode afetar a residência e a segurança dos dados. Para obter uma arquitetura de referência para implantações de várias regiões, consulte Executar um aplicativo de N camadas em várias regiões do Azure para alta disponibilidade.

Pares regionais

Uma geografia do Azure é uma área definida do mundo que contém pelo menos uma região do Azure, cada uma com um ou mais datacenters. Cada região do Azure é emparelhada com outra região na mesma geografia em um par regional. Os pares regionais não são atualizados ao mesmo tempo e, se um desastre atingir ambas as regiões, uma das regiões é priorizada para voltar a ficar online primeiro. Para continuidade de negócios, você deve implantar aplicativos altamente confidenciais pelo menos em pares regionais se implantar em várias regiões.

Para obter mais detalhes, consulte Continuidade de negócios e recuperação de desastres (BCDR): Regiões Emparelhadas do Azure. O whitepaper Achieve compatible data residency and security with Azure discute a residência de dados e o que fazer para atender aos requisitos de residência de dados.

Replicação entre regiões

Em arquiteturas IaaS, a replicação de dados entre regiões é de responsabilidade do aplicativo. O cenário de replicação mais comum usa tecnologias de replicação de banco de dados incorporadas ao produto de servidor de banco de dados, como SQL Server Always On Availability Groups, Oracle Data Guard ou MySQL Replication.

Configurar a replicação entre servidores de banco de dados IaaS não é simples e você precisa levar em conta os requisitos de continuidade de negócios. Os serviços de banco de dados do Azure, como o Banco de Dados SQL do Azure, o Banco de Dados do Azure para MySQL e o Azure Cosmos DB , facilitam a replicação entre regiões, mas podem não atender aos requisitos de segurança para cargas de trabalho altamente confidenciais.

Para obter mais informações e orientações para implantações SQL Server e Oracle em várias regiões, consulte:

Emparelhamento entre regiões

Você pode habilitar a comunicação segura entre redes virtuais em diferentes regiões usando o emparelhamento de rede virtual global. O emparelhamento global funciona da mesma forma que o emparelhamento dentro da região. O tráfego entre regiões é executado através do backbone da Microsoft, não atravessa a Internet e é isolado de outro tráfego. Para obter mais segurança, você pode implantar NVAs VPN em ambas as regiões e usar rotas definidas pelo usuário para forçar o tráfego entre regiões sobre os NVAs, semelhante à implantação de uma DMZ.

Roteamento de tráfego de failover

Com pontos de extremidade públicos, você pode usar o Gerenciador de Tráfego ou o Azure Front Door para direcionar o tráfego para a região ativa ou a região mais próxima em uma configuração de failover ativo-ativo . No entanto, o Gerenciador de Tráfego e o Azure Front Door exigem pontos de extremidade públicos para monitorar a disponibilidade, e suas entradas DNS correspondentes são públicas. Para cargas de trabalho altamente confidenciais, a solução alternativa é implantar o DNS local e alterar as entradas para a região ativa para failover.

Gestão e governação

Proteger seus aplicativos IaaS altamente confidenciais requer mais do que apenas implantar as arquiteturas corretas e implementar regras de segurança de rede. Como os ambientes de nuvem são facilmente alterados, é especialmente importante garantir que as alterações possam ser feitas apenas com determinadas permissões e dentro dos limites das políticas de segurança. Por exemplo, você deve impedir que um ator mal-intencionado possa alterar uma regra de segurança de rede para permitir o tráfego da Internet.

Para implantar cargas de trabalho no Azure, você precisa de uma ou mais contas de gerenciamento. Proteger contas de gerenciamento é fundamental para proteger suas cargas de trabalho. Para obter mais informações, consulte Acesso privilegiado seguro para implantações híbridas e em nuvem no Microsoft Entra ID.

Use os recursos em sua sub-rede de gerenciamento para conceder acesso à camada de aplicativo somente às pessoas que precisam gerenciar essa camada. Por exemplo, você pode usar o Microsoft Identity Manager com o Microsoft Entra ID. No entanto, para cenários nativos da nuvem, o Microsoft Entra Privileged Identity Management (PIM) é preferido.

Há várias outras maneiras de controlar funções e políticas do Azure:

  • O controle de acesso baseado em função do Azure (Azure RBAC) para recursos do Azure permite atribuir funções internas ou personalizadas aos usuários, para que eles tenham apenas os privilégios de que precisam. Você pode combinar o RBAC do Azure com o PIM para implementar um fluxo de trabalho de aprovação auditado que eleva os privilégios por um período de tempo limitado.
  • As políticas impõem regras, padrões e SLAs corporativos. A Política do Azure é um serviço do Azure que cria, atribui e gerencia políticas e avalia seus recursos para conformidade com políticas.
  • Os Azure Blueprints combinam atribuições de função, atribuições de política e modelos de implantação para definir um conjunto de recursos replicáveis do Azure que implementam e seguem os padrões, padrões e requisitos de uma organização. Os blueprints são uma maneira declarativa de orquestrar a implantação de modelos de recursos e outros artefatos. Você mesmo pode criar plantas ou aproveitar as plantas existentes. Por exemplo, o plano de Serviços Compartilhados da ISO 27001 implanta um hub de serviços compartilhados que você pode modificar e estender de acordo com os requisitos da sua organização.

Monitorização

O Microsoft Defender for Cloud fornece monitoramento e alertas que ajudam a manter a segurança do seu ambiente. O serviço gratuito verifica automaticamente vulnerabilidades, como patches de sistema operacional ausentes, configuração incorreta de segurança e segurança básica de rede. A versão paga Standard oferece recursos adicionais, como análise comportamental, Adaptive Network Harening e acesso a VM JIT. Para obter uma lista completa de recursos, consulte Cobertura de recursos para máquinas. O Defender for Cloud também fornece proteção contra ameaças para outros recursos, como o Azure Key Vault.

Você pode usar o Azure Monitor para monitoramento e análise adicionais. Para monitorar a identidade e o acesso, você pode rotear os logs de atividade do Microsoft Entra para o Azure Monitor. Você também pode monitorar VMs, redes e o Firewall do Azure e analisar logs importados com um poderoso recurso de consulta de log. Você pode integrar o Azure Monitor ao seu Gerenciador de Informações de Segurança e Eventos (SIEM), que pode ser um SIEM de terceiros ou o Microsoft Sentinel.