Recomendações de segurança para o Ambiente 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 muitos recursos 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 tem muitos recursos de segurança avançados internos, como Conexão Inversa, onde nenhuma porta de rede de entrada precisa estar aberta, o que reduz o risco envolvido em ter áreas de trabalho remotas acessíveis de qualquer lugar. O serviço também se beneficia de muitos outros recursos de segurança do Azure, como autenticação multifator e acesso condicional. Este artigo descreve as etapas que você pode seguir como administrador para manter suas implantações da Área de Trabalho Virtual do Azure seguras, quer você forneça áreas de trabalho e aplicativos para usuários em sua organização ou para usuários externos.

Responsabilidades partilhadas de segurança

Antes da Área de Trabalho Virtual do Azure, as soluções de virtualização locais, como os Serviços de Área de Trabalho Remota, exigem conceder aos usuários acesso a funções como Gateway, Broker, Web Access e assim por diante. Essas funções tinham que ser totalmente redundantes e capazes de lidar com a capacidade de pico. Os administradores instalariam essas funções como parte do sistema operacional Windows Server e elas tinham que ingressar no domínio com portas específicas acessíveis a conexões públicas. Para manter as implantações seguras, os administradores tinham que se certificar constantemente de que tudo na infraestrutura fosse mantido e atualizado.

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

Embora alguns componentes já estejam protegidos para seu ambiente, você precisará configurar outras áreas para atender às necessidades de segurança da sua organização ou cliente. Aqui estão os componentes dos quais você é responsável pela segurança em sua implantação da Área de Trabalho Virtual do Azure:

Componente Responsabilidade
Identidade Cliente ou parceiro
Dispositivos do utilizador (telemóvel e PC) Cliente ou parceiro
Segurança da aplicação Cliente ou parceiro
Sistema operacional do host da sessão Cliente ou parceiro
Configuração de implantação Cliente ou parceiro
Controlos de rede Cliente ou parceiro
Plano de controle de virtualização Microsoft
Anfitriões físicos Microsoft
Rede física Microsoft
Datacenter físico Microsoft

Limites de segurança

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

Limite de segurança Descrição
Limite da rede Um ponto de extremidade de rede não autorizado não pode acessar ou adulterar código e dados no dispositivo de um cliente.
Limite do kernel Um processo de modo de usuário não administrativo não pode acessar ou adulterar o código e os dados do kernel. Administrador para kernel não é um limite de segurança.
Limite do processo Um processo de modo de usuário não autorizado não pode acessar ou adulterar o código e os dados de outro processo.
Limite da área restrita do AppContainer Um processo de sandbox baseado em AppContainer não pode acessar ou adulterar código e dados fora da área restrita com base nos recursos do contêiner.
Limite do usuário Um usuário não pode acessar ou adulterar o código e os dados de outro usuário sem ser autorizado.
Limite da sessão Uma sessão de usuário não pode acessar ou adulterar outra sessão de usuário sem ser autorizada.
Limite do navegador da Web Um site não autorizado não pode violar a política de mesma origem, nem pode acessar ou adulterar o código nativo e os dados da área restrita do navegador da Web Microsoft Edge.
Limite da máquina virtual Uma máquina virtual convidada Hyper-V não autorizada não pode acessar ou adulterar o código e os dados de outra máquina virtual convidada; isso inclui contêineres isolados do Hyper-V.
Limite do Modo Seguro Virtual (VSM) O código executado fora do processo ou enclave confiável do VSM não pode acessar ou adulterar dados e código dentro do processo confiável.

Você também precisará fazer certas escolhas sobre limites de segurança caso a caso. Por exemplo, se um utilizador na sua organização precisar de privilégios de administrador local para instalar aplicações, terá de lhe dar um ambiente de trabalho pessoal em vez de um anfitrião de sessão partilhado. Não recomendamos conceder aos usuários privilégios de administrador local em cenários agrupados de várias sessões, pois esses usuários podem cruzar os limites de segurança para sessões ou permissões de dados NTFS, desligar VMs de várias sessões ou fazer outras coisas que possam interromper o serviço ou causar perdas de dados.

Usuários da mesma organização, como profissionais do conhecimento com aplicativos que não exigem privilégios de administrador, são ótimos candidatos para hosts de sessão múltipla, como o Windows 11 Enterprise com várias sessões. Esses hosts de sessão reduzem os custos para sua organização porque vários usuários podem compartilhar uma única VM, com apenas os custos gerais de uma VM por usuário. Com produtos de gerenciamento de perfil de usuário como FSLogix, os usuários podem receber qualquer VM em um pool de hosts sem notar interrupções de serviço. Esse recurso também permite otimizar custos fazendo coisas como desligar 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 Ative Directory e Microsoft Entra ID. Também recomendamos que você tenha uma assinatura separada para esses usuários para hospedar recursos do Azure, como a Área de Trabalho Virtual do Azure e VMs.

Em muitos casos, o uso de várias sessões é uma maneira aceitável de reduzir custos, mas se recomendamos isso 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 onde as pessoas colaboram e podem acessar as informações pessoais umas das outras é uma organização com um alto nível de confiança.

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

As implantações de várias sessões se beneficiariam de uma estratégia de segurança em profundidade que adiciona mais limites de segurança que impedem que os usuários dentro e fora da organização obtenham acesso não autorizado às informações pessoais de outros usuários. O acesso não autorizado a dados acontece devido a um erro no processo de configuração pelo administrador do sistema, como uma vulnerabilidade de segurança não revelada ou uma vulnerabilidade conhecida que ainda não foi corrigida.

Não recomendamos conceder aos usuários que trabalham para empresas diferentes ou concorrentes acesso ao mesmo ambiente de várias sessões. Esses cenários têm vários limites de segurança que podem ser atacados ou abusados, como rede, kernel, processo, usuário ou sessões. Uma única vulnerabilidade de segurança pode causar roubo não autorizado de dados e credenciais, vazamentos de informações pessoais, roubo de identidade e outros problemas. Os provedores de ambientes virtualizados são responsáveis por oferecer sistemas bem projetados, com vários limites de segurança fortes e recursos de segurança extras habilitados sempre que possível.

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 (SO) de várias sessões do Windows Enterprise.
Os usuários precisam de privilégios administrativos Use um pool de hosts pessoal e atribua a cada usuário seu próprio host de sessão.
Usuários de diferentes organizações conectando-se Separe o locatário do Azure e a assinatura do Azure