Recomendações de segurança para a Área de Trabalho Virtual do Azure

  • 7 minutos

A Área de Trabalho Virtual do Azure é um serviço de área de trabalho virtual gerenciado que inclui várias funcionalidades de segurança para manter sua organização segura. A arquitetura da Área de Trabalho Virtual do Azure compreende muitos componentes que compõem o serviço que conecta os usuários a suas áreas de trabalho e aplicativos.

A Área de Trabalho Virtual do Azure possui vários recursos de segurança avançados internos, como a Conexão Reversa, que não exige portas de redes de entrada abertas e reduz o risco envolvido em ter áreas de trabalho remotas acessíveis de qualquer lugar. O serviço também dispõe de benefícios de muitos outros recursos de segurança do Azure como, por exemplo, a autenticação multifator e o acesso condicional. Este artigo descreve as etapas que um administrador pode seguir para manter as implantações da Área de Trabalho Virtual do Azure seguras, independentemente de fornecer áreas de trabalho e aplicativos aos usuários na organização ou aos usuários externos.

Responsabilidade compartilhada pela segurança

Antes da Área de Trabalho Virtual do Azure, soluções locais de virtualização como os Serviços de Área de Trabalho Remota exigiam que os usuários recebessem funções como Gateway, Broker, Acesso via Web e assim por diante. Essas funções tinham de ser totalmente redundantes e capazes de lidar com a capacidade de pico. Os administradores instalavam essas funções como parte do sistema operacional Windows Server e precisavam conectá-las ao domínio com portas específicas acessíveis para conexões públicas. Para manter as implantações seguras, os administradores tinham de garantir constantemente que tudo na infraestrutura estava adequado e atualizado.

No entanto, para a maioria dos serviços de nuvem há um conjunto compartilhado de responsabilidades de segurança entre a Microsoft e o cliente ou o parceiro. Na Área de Trabalho Virtual do Azure, a maioria dos componentes são gerenciados pela Microsoft, mas, os hosts da sessão e alguns serviços e componentes de suporte são gerenciados pelo cliente ou pelo parceiro. Para saber mais sobre os componentes da Área de Trabalho Virtual do Azure gerenciados pela Microsoft, consulte Arquitetura e resiliência do serviço da Área de Trabalho Virtual do Azure.

Embora alguns componentes já estejam protegidos para o ambiente, será necessário que você configure as outras áreas para ajustá-las às necessidades de segurança da organização ou do cliente. Estes são os componentes pelos quais você será responsável pela segurança na implantação da Área de Trabalho Virtual do Azure:

Componente Capacidade de resposta
Identidade Cliente ou parceiro
Dispositivos de usuário (móvel e PC) Cliente ou parceiro
Segurança do aplicativo Cliente ou parceiro
Sistema operacional de host da sessão Cliente ou parceiro
Configuração de implantação Cliente ou parceiro
Controles de rede Cliente ou parceiro
Plano de controle de virtualização Microsoft
Hosts físicos Microsoft
Rede física Microsoft
Datacenter físico Microsoft

Limites de segurança

Limites de segurança separam o código e os dados de domínios de segurança com diferentes níveis de confiança. Por exemplo, há geralmente um limite de segurança entre o modo kernel e o modo de usuário. A maioria dos softwares e dos serviços da Microsoft depende de vários limites de segurança para isolar dispositivos em redes, VMs (máquinas virtuais) e aplicativos em dispositivos. A tabela a seguir lista cada limite de segurança do Windows e o papel deles na segurança geral.

Marco de delimitação de segurança Descrição
Limite de rede Um ponto de extremidade de rede não autorizado não pode acessar nem adulterar o código e os dados no dispositivo de um cliente.
Limite de kernel Um processo de modo de usuário não administrativo não pode acessar nem adulterar o código e os dados do kernel. A função de administrador de kernel não é um limite de segurança.
Limite de processo Um processo de modo de usuário não autorizado não pode acessar nem adulterar o código e os dados de outro processo.
Limite de área restrita do AppContainer Um processo de área restrita baseado no AppContainer não pode acessar nem adulterar o código e os dados fora da área restrita com base nos recursos do contêiner.
Limite de usuário Um usuário não pode acessar nem adulterar o código e os dados de outro usuário sem autorização.
Limite de sessão Uma sessão de usuário não pode acessar nem adulterar outra sessão de usuário sem autorização.
Limite de navegador da Web Um site não autorizado não pode violar a política de mesma origem nem acessar/adulterar o código nativo e os dados da área restrita do navegador Web Microsoft Edge.
Limite de máquina virtual Uma máquina virtual Hyper-V convidada não autorizada não pode acessar nem adulterar o código e os dados de outra máquina virtual convidada, o que inclui contêineres isolados do Hyper-V.
Limite do VSM (modo de segurança virtual) Os códigos que são executados fora do enclave ou do processo confiável do VSM não podem acessar nem adulterar o código e os dados do processo confiável.

Também pode ser necessário escolher os limites de segurança caso a caso. Por exemplo, se um usuário na sua organização precisa ter privilégios de administrador local para instalar aplicativos, é necessário que você forneça ao administrador uma área de trabalho pessoal em vez de um host da sessão compartilhado. Não é recomendável conceder privilégios de administrador local para usuários em cenários de pool de múltiplas sessões porque esses usuários poderão ultrapassar os limites de segurança das sessões ou permissões de dados NTFS, desligar VMs com múltiplas sessões ou realizar outras ações que poderão interromper o serviço ou causar perdas de dados.

Usuários da mesma organização, por exemplo, trabalhadores do conhecimento com aplicativos que não exigem privilégios de administrador, são excelentes candidatos para hosts da sessão com múltiplas sessões, como o Windows 11 Enterprise com múltiplas seções. Esses hosts da sessão reduzem os custos para a organização, já que vários usuários poderão compartilhar uma única VM e apenas com os custos de sobrecarga de uma VM por usuário. Com produtos de gerenciamento de perfil do usuário como o FSLogix, é possível atribuir usuários a VMs em um pool de host sem que interrupções no serviço sejam percebidas. Esse recurso também permite otimizar os custos, como através do desligamento de VMs fora do horário de pico.

Se sua situação exigir que usuários de organizações diferentes se conectem à sua implantação, recomendamos que você tenha um locatário separado para serviços de identidade, como o Active Directory e o Microsoft Entra ID. Também é recomendável que esses usuários tenham uma assinatura separada para hospedar recursos do Azure, como VMs e Área de Trabalho Virtual do Azure.

Em muitos casos, o uso de várias sessões é uma maneira aceitável de reduzir os custos, mas a recomendação dele depende do nível de confiança entre os usuários com acesso simultâneo a uma instância compartilhada de várias sessões. Normalmente, os usuários que pertencem à mesma organização têm uma relação de confiança suficiente e acordada. Por exemplo, um departamento ou grupo de trabalho em que as pessoas colaboram e podem acessar as informações pessoais umas das outras é uma organização com alto nível de confiança.

O Windows usa controles e limites de segurança para garantir que os processos e os dados do usuário sejam isolados entre as sessões. No entanto, ele ainda fornece acesso à instância em que o usuário está trabalhando.

Implantações com múltiplas sessões se beneficiam de uma estratégia de segurança aprofundada que adiciona mais limites de segurança para evitar que usuários, tanto dentro quanto fora da organização, recebam acesso não autorizado às informações pessoais de outros usuários. O acesso não autorizado a dados ocorre devido a um erro do administrador do sistema no processo de configuração, como uma vulnerabilidade de segurança não divulgada ou uma vulnerabilidade conhecida que ainda não foi corrigida.

Não é recomendável conceder a usuários que trabalhem em empresas diferentes ou concorrentes o acesso ao mesmo ambiente com múltiplas sessões. Esses cenários têm vários limites de segurança que podem ser atacados ou aproveitados, como redes, kernel, processos, usuários ou sessões. Uma única vulnerabilidade de segurança pode causar roubos de credenciais e dados não autorizados, vazamentos de informações pessoais, roubo de identidade, entre outros problemas. Os provedores de ambientes virtualizados são responsáveis por oferecer, sempre que possível, sistemas bem projetados com diversos limites de segurança sólidos e recursos adicionais de segurança habilitados.

A tabela resume nossas recomendações para cada cenário.

Cenário de nível de confiança Solução recomendada
Usuários de uma organização com privilégios padrão Use um sistema operacional Windows Enterprise com múltiplas sessões.
Os usuários exigem privilégios administrativos Use um pool de host pessoal e atribua a cada usuário seu próprio host da sessão.
Usuários de diferentes organizações se conectam Separe a assinatura do Azure e o locatário do Azure.