Editar

Compartilhar via

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

Azure Disk Encryption
Firewall do Azure
Cofre de Chave do Azure
Microsoft Defender para Nuvem
Rede Virtual do Azure

Há muitas considerações de segurança para implantar aplicativos de IaaS (infraestrutura como serviço) no Azure. Este artigo baseia-se em arquiteturas de referência para cargas de trabalho baseadas em máquina virtual e infraestruturas de rede híbrida para se concentrar na segurança de cargas de trabalho de IaaS altamente confidenciais no Azure, com base nos conceitos básicos de segurança do Azure.

Confira também a Visão geral de segurança das máquinas virtuais do Azure e as Melhores práticas de segurança para cargas de trabalho de IaaS no Azure.

VMs do Azure

A plataforma de computação do Azure se baseia na virtualização de computadores. 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 VMs (máquinas virtuais) do Hyper-V convidado no nó. Todo o código de usuário é executado nas VMs. Para obter instruções básicas de implantação de VM do Azure, confira Executar uma VM do Linux no Azure ou Executar uma VM do Windows no Azure. A maioria dos processos de implantação é a mesma para os dois SOs (sistemas operacionais), mas as ferramentas específicas do sistema operacional, como a criptografia de disco, podem diferir.

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

A Microsoft fornece proteção de DDoS (negação de serviço distribuída) básica como parte da plataforma do Azure. Aplicativos que têm pontos de extremidade públicos podem usar a Proteção contra DDoS do Azure Standard 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 VPN (rede virtual privada) ou de uma linha concedida.

Arquiteturas de N camadas

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

  • HA (Alta disponibilidade). Os aplicativos de HA devem estar disponíveis mais de 99,9% das vezes. Colocar VMs na camada em diferentes zonas de disponibilidade do Azure garante a HA, pois as zonas de disponibilidade abrangem um ou mais datacenters, fornecendo resiliência por meio da resistência à falha do datacenter. As regiões que não dão 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 a 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. Redes virtuais e sub-redes segmentam sua rede, permitindo um gerenciamento de segurança mais fácil e roteamento avançado.
  • DNS (Sistema de Nomes de Domínio). 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.

Backup e restauração

Para proteger contra erros humanos, exclusão de dados mal-intencionados e ransomware, faça backup de pelo menos suas VMs da camada de dados. O Backup do Azure poderá fazer backup e restaurar VMs criptografadas se puder acessar as chaves de criptografia no Azure Key Vault.

Para as camadas Web e empresarial, você pode usar regras de dimensionamento automático do conjunto de dimensionamento de máquinas virtuais para automaticamente destruir VMs comprometidas e implantar novas instâncias de VM de uma imagem base.

Isolamento de computação

Em cada ponto de extremidade de rede ou nó do Azure, o hipervisor e um sistema operacional raiz especial garantem que as VMs convidadas não possam acessar o servidor host físico, e o código do usuário é executado apenas em VMs convidadas. Isso impede que os usuários obtenham acesso bruto de leitura, gravação ou execução no sistema, bem como minimiza o risco de compartilhamento de recursos. O Azure protege contra todos os ataques de temporização e vizinhos ruidosos por meio do hipervisor e de um algoritmo avançado de posicionamento de VM. Para obter mais informações, confira Isolamento de computação.

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

VMs isoladas

Essas VMs isoladas são VMs grandes que são isoladas para um tipo específico de hardware e são dedicadas a um único cliente. Utilizar um tamanho de VM isolada garante que a sua VM só seja executada na 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 exige e podem criar uma grande sobrecarga de custo. Para reduzir a sobrecarga, você pode executar várias camadas de aplicativo em uma única VM com virtualização aninhada ou em processos ou contêineres diferentes. Você ainda precisa implantar diferentes VMs em zonas de disponibilidade para resiliência e executar dispositivos de DMZ (zona desmilitarizada) em VMs separadas. Combinar vários aplicativos em uma infraestrutura por razões econômicas também pode entrar em conflito com 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 um ano de aviso prévio.

Hosts Dedicados do Azure

O Host Dedicado do Azure é a solução de isolamento de computação preferencial 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 da VM para evitar vizinhos ruidosos.

Hosts 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 atender às políticas de segregação de aplicativos. Você ainda deve executar VMs de DMZ em um host diferente, para evitar qualquer ataque de temporização de uma VM comprometida na DMZ.

Criptografia

A criptografia de dados é um componente importante da proteção de cargas de trabalho. A criptografia codifica informações para que somente receptores autorizados possam decodificá-la usando uma chave ou certificado. A criptografia inclui criptografia de disco, para criptografia de dados inativos e TLS (Segurança de Nível de Transporte) para criptografia ativa nas redes.

Cofre de Chave do Azure

Você pode proteger chaves de criptografia e certificados armazenando-os no Azure Key Vault, uma solução HSM (Módulo de Segurança de Hardware) na nuvem validada para padrão FIPS 140-2 nível 2. Para obter melhores práticas para permitir que apenas aplicativos e usuários autorizados acessem o Key Vault, confira Acesso seguro a um cofre de chaves.

Para proteger chaves no Key Vault, você pode habilitar a exclusão temporária, o que garante que as chaves excluídas sejam recuperáveis. Para proteção adicional, você pode fazer backup de chaves individuais para 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 Conector do SQL Server para Microsoft Azure Key Vault para obter chaves para TDE (Transparent Data Encryption), CLE (criptografia de nível de coluna) e criptografia de backup. Para mais detalhes, confira Configurar a integração do Azure Key Vault para SQL Server em máquinas virtuais do Azure.

Azure Disk Encryption

O Azure Disk Encryption usa o 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 é integrado ao Azure Key Vault para ajudar você a controlar e gerenciar as chaves de criptografia de disco e os segredos. Cada VM gera suas próprias chaves de criptografia e as armazena no Azure Key Vault. Para configurar o Azure Key Vault para habilitar o Azure Disk Encryption, confira Criar e configurar um cofre de chaves para o Azure Disk Encryption.

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

Criptografia protegida por HSM

Para obter mais informações sobre chaves protegidas por HSM, confira Como gerar e transferir chaves protegidas por HSM para o Azure Key Vault.

Criptografia de tráfego de rede

Os protocolos de rede, como o HTTPS, criptografam dados em trânsito com certificados. O tráfego cliente para aplicativo geralmente usa um certificado de uma AC (autoridade de certificação) confiável. Os aplicativos internos podem usar um certificado de uma AC interna ou de uma AC pública, como DigiCert ou GlobalSign. A comunicação de camada a camada normalmente usa um certificado emitido por uma AC 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, confira Métodos de criação de certificado.

O Azure Key Vault pode atuar como uma AC de certificado autoassinado para tráfego de camada a camada. A extensão de VM do Key Vault 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 VM do Key Vault, confira Extensão da máquina virtual do Key Vault para Linux e Extensão da máquina virtual do Key Vault para Windows.

O Key Vault também pode armazenar chaves para protocolos de rede que não usam certificados. As cargas de trabalho personalizadas podem exigir script de uma extensão de script personalizado que recupera uma chave de Key Vault e a armazena para que os aplicativos usem. Os aplicativos também podem usar a identidade gerenciada de uma VM para recuperar segredos diretamente do Key Vault.

Segurança de rede

Os NSGs (grupos de segurança de rede) filtram o tráfego entre recursos em redes virtuais do Azure. As regras de segurança do NSG permitem ou negam o 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 o 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. Um registro de fluxo permite que um NSG esteja com estado. Por exemplo, se você especificar uma regra de segurança de saída para algum endereço pela porta 443, não será necessário especificar uma regra de segurança de entrada para a resposta ao tráfego de saída. Você precisará 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 regra de segurança de rede. Uma marca de serviço do Azure Key Vault pode permitir que uma VM recupere certificados, chaves e segredos do Azure Key Vault.

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

Você pode usar NVAs como 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. Você também pode implantar NVAs de terceiros no Azure Marketplace. Para tornar esses NVAs altamente disponíveis, confira Implantar soluções de virtualização de rede altamente disponíveis.

Grupos de segurança do aplicativo

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

Grupos de segurança do aplicativo

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 a nuvens públicas como o Azure. Há várias maneiras de conectar redes locais a aplicativos em execução no Azure:

  • Ponto de extremidade público pela Internet. Você pode contar com identidade, HTTPS (segurança no nível do transporte) e o gateway de aplicativo para proteger o aplicativo, potencialmente em combinação com um firewall. No entanto, para cargas de trabalho altamente confidenciais, não é recomendável expor um ponto de extremidade público pela Internet.
  • Gateway de VPN do Azure ou 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. Também será possível executar um gateway de terceiros em uma VM se você tiver requisitos específicos sem suporte pelo gateway de VPN do Azure.
  • ExpressRoute. Conexões do ExpressRoute usam uma conexão privada dedicada por meio de um provedor 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.
    • Failover do ExpressRoute com VPN. Essa opção usa o ExpressRoute em condições normais, mas faz failover para uma conexão VPN se há uma perda de conectividade no circuito do ExpressRoute, fornecendo disponibilidade mais alta.
    • VPN no ExpressRoute. Essa opção é a melhor para cargas de trabalho altamente confidenciais. O ExpressRoute 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 diretrizes sobre como escolher entre diferentes tipos de conectividade híbrida, confira Escolher uma solução para conectar uma rede local ao Azure.

Implantar uma DMZ

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

Uma arquitetura como a do DMZ de Rede entre o Azure e um datacenter local implanta todos os serviços de aplicativos e DMZ na mesma rede virtual, com regras NSG e rotas definidas pelo usuário para isolar as sub-redes de aplicativo e DMZ. Essa arquitetura pode disponibilizar a sub-rede de gerenciamento por meio da 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 emergência. Uma solução melhor é usar o Azure Bastion, que permite o acesso diretamente do portal do Azure limitando a exposição de endereços IP públicos.

Você também pode usar o acesso à VM JIT (just-in-time) 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 RDP (protocolo de área de trabalho remota) e SSH (secure shell) por padrão. Após a 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 um gateway VPN e/ou ExpressRoute, NVA de firewall, hosts de gerenciamento, infraestrutura de identidade e outros serviços compartilhados. As redes virtuais spoke estão conectadas ao hub com emparelhamento de rede virtual. Uma rede virtual do Azure não permite roteamento transitivo pelo hub de um spoke para outro. O tráfego spoke a spoke só é possível por meio dos dispositivos de firewall no hub. Essa arquitetura isola efetivamente os aplicativos uns dos outros.

Implantação em várias regiões

A continuidade dos negócios e recuperação de desastres pode exigir a implantação do aplicativo em várias regiões do Azure, o que pode afetar a residência e a segurança dos dados.

Pares regionais

Uma geografia do Azure é uma área definida no 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 na mesma área geográfica 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 será priorizada para voltar a ficar online primeiro. Para a continuidade dos negócios, você deverá implantar aplicativos altamente confidenciais pelo menos em pares regionais se você implantar em várias regiões.

Para saber mais, confira BCDR (continuidade dos negócios e recuperação de desastres): regiões emparelhadas do Azure. O whitepaper Obter segurança e residência de dados em conformidade com o Azure discute a residência de dados e o que fazer para obter os requisitos de residência de dados.

Replicação entre regiões

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

A configuração da replicação entre servidores de banco de dados de IaaS não é simples e você precisa levar em conta os requisitos de continuidade dos negócios. Os serviços de banco de dados do Azure, como Banco de Dados SQL do Azure, Banco de Dados do Azure para MySQL e 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 diretrizes para implantações de SQL Server e Oracle de várias regiões, confira:

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 passa pelo 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 as 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.

Gerenciamento e governança

Proteger seus aplicativos de 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 só possam ser feitas 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 é essencial para proteger suas cargas de trabalho. Para mais informações, confira Proteger o acesso privilegiado para implantações de nuvem e híbridas no Microsoft Entra ID.

Use os recursos em sua sub-rede de gerenciamento para conceder acesso à camada de aplicativo apenas para 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 de nuvem, é preferível o Microsoft Entra Privileged Identity Management (PIM).

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

  • O RBAC (controle de acesso baseado em função) do Azure para recursos do Azure permite atribuir funções internas ou personalizadas aos usuários, para que eles tenham apenas os privilégios necessários. Você pode combinar o RBAC do Azure com o PIM para implementar um fluxo de trabalho de aprovação auditado que eleva privilégios por um período de tempo limitado.
  • As políticas impõem regras corporativas, padrões e SLAs. O Azure Policy é um serviço do Azure que cria, atribui e gerencia políticas e avalia seus recursos para conformidade com a política.
  • O Azure Blueprints combina 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 e requisitos de uma organização. O Blueprints é um modo declarativo de orquestrar a implantação de vários modelos de recursos e outros artefatos. Você pode criar blueprints por conta própria ou aproveitar os blueprints existentes. Por exemplo, o blueprint dos Serviços Compartilhados ISO 27001 implanta um hub de serviços compartilhados que você pode modificar e estender para os requisitos da sua organização.

Monitoramento

O Microsoft Defender para Nuvem fornece monitoramento e alertas que ajudam a manter a segurança do seu ambiente. O serviço gratuito verifica automaticamente se há vulnerabilidades, como patches de sistema operacional ausentes, configuração incorreta de segurança e segurança de rede básica. A versão paga Standard oferece recursos adicionais, como análise comportamental, proteção de rede adaptável e acesso à VM JIT. Para obter uma lista completa de recursos, consulte Cobertura de recursos para computadores. O Defender para Nuvem 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 atividades do Microsoft Entra para o Azure Monitor. Você também pode monitorar as VMs, as redes e o Firewall do Azure e analisar logs importados com funcionalidade avançada de consulta de log. Você pode integrar o Azure Monitor ao SIEM (Gerenciador de Eventos e Informações de Segurança), que pode ser um SIEM de terceiros ou o Microsoft Sentinel.