Isolamento na nuvem pública do Azure

O Azure permite que você execute aplicativos e máquinas virtuais (VMs) em infraestrutura física compartilhada. Uma das principais motivações econômicas para executar aplicativos em um ambiente de nuvem é a capacidade de distribuir o custo de recursos compartilhados entre vários clientes. Esta prática de multilocação melhora a eficiência através da multiplexação de recursos entre clientes díspares a baixos custos. Infelizmente, ele também introduz o risco de compartilhar servidores físicos e outros recursos de infraestrutura para executar seus aplicativos confidenciais e VMs que podem pertencer a um usuário arbitrário e potencialmente mal-intencionado.

Este artigo descreve como o Azure fornece isolamento contra usuários mal-intencionados e não mal-intencionados e serve como um guia para arquitetar soluções de nuvem, oferecendo várias opções de isolamento para arquitetos.

Isolamento ao nível do inquilino

Um dos principais benefícios da computação em nuvem é o conceito de uma infraestrutura comum compartilhada entre vários clientes simultaneamente, levando a economias de escala. Este conceito é chamado de multilocação. A Microsoft trabalha continuamente para garantir que a arquitetura multilocatária do Microsoft Cloud Azure ofereça suporte a padrões de segurança, confidencialidade, privacidade, integridade e disponibilidade.

Na área de trabalho ativada na nuvem, um inquilino pode ser definido com um cliente ou uma organização que possui e gere uma instância específica do referido serviço em nuvem. Com a plataforma de identidade fornecida pelo Microsoft Azure, um locatário é simplesmente uma instância dedicada do Microsoft Entra ID que sua organização recebe e possui quando se inscreve em um serviço de nuvem da Microsoft.

Cada diretório do Microsoft Entra é distinto e separado de outros diretórios do Microsoft Entra. Assim como um prédio de escritórios corporativos é um ativo seguro específico apenas para sua organização, um diretório Microsoft Entra também foi projetado para ser um ativo seguro para uso apenas pela sua organização. A arquitetura do Microsoft Entra isola os dados do cliente e as informações de identidade da co-mistura. Isso significa que os usuários e administradores de um diretório do Microsoft Entra não podem acessar dados acidental ou maliciosamente em outro diretório.

Azure Tenancy

O arrendamento do Azure (Subscrição do Azure) refere-se a uma relação "cliente/faturação" e a um inquilino exclusivo no Microsoft Entra ID. O isolamento em nível de locatário no Microsoft Azure é obtido usando a ID do Microsoft Entra e o controle de acesso baseado em função do Azure oferecido por ele. Cada assinatura do Azure está associada a um diretório do Microsoft Entra.

Usuários, grupos e aplicativos desse diretório podem gerenciar recursos na assinatura do Azure. Você pode atribuir esses direitos de acesso usando o portal do Azure, as ferramentas de linha de comando do Azure e as APIs de Gerenciamento do Azure. Um locatário do Microsoft Entra é logicamente isolado usando limites de segurança para que nenhum cliente possa acessar ou comprometer colocatários, seja maliciosamente ou acidentalmente. O Microsoft Entra ID é executado em servidores "bare metal" isolados em um segmento de rede segregado, onde a filtragem de pacotes no nível do host e o Firewall do Windows bloqueiam conexões e tráfego indesejados.

• O acesso aos dados no Microsoft Entra ID requer autenticação do usuário por meio de um serviço de token de segurança (STS). As informações sobre a existência, o estado habilitado e a função do usuário são usadas pelo sistema de autorização para determinar se o acesso solicitado ao locatário de destino está autorizado para esse usuário nesta sessão.

• Os inquilinos são recipientes discretos e não há relação entre eles.

• Nenhum acesso entre locatários, a menos que o administrador do locatário o conceda por meio de contas de usuário de federação ou provisionamento de outros locatários.

• O acesso físico aos servidores que compõem o serviço Microsoft Entra e o acesso direto aos sistemas back-end do Microsoft Entra ID são restritos.

• Os usuários do Microsoft Entra não têm acesso a ativos físicos ou locais e, portanto, não é possível que ignorem as verificações lógicas de política do RBAC do Azure indicadas a seguir.

Para necessidades de diagnóstico e manutenção, é necessário e usado um modelo operacional que emprega um sistema de elevação de privilégios just-in-time. O Microsoft Entra Privileged Identity Management (PIM) introduz o conceito de administrador elegível. Os administradores elegíveis devem ser usuários que precisam de acesso privilegiado de vez em quando, mas não todos os dias. A função está inativa até que o utilizador precise de acesso. Nessa altura, o utilizador realiza um processo de ativação e torna-se num administrador ativo durante uma quantidade pré-determinada de tempo.

O Microsoft Entra ID hospeda cada locatário em seu próprio contêiner protegido, com políticas e permissões para e dentro do contêiner de propriedade exclusiva e gerenciado pelo locatário.

O conceito de contêineres de locatário está profundamente enraizado no serviço de diretório em todas as camadas, desde portais até armazenamento persistente.

Mesmo quando os metadados de vários locatários do Microsoft Entra são armazenados no mesmo disco físico, não há nenhuma relação entre os contêineres além do que é definido pelo serviço de diretório, que, por sua vez, é ditado pelo administrador do locatário.

Controlo de acesso baseado em funções do Azure (RBAC do Azure)

O controle de acesso baseado em função do Azure (Azure RBAC) ajuda você a compartilhar vários componentes disponíveis em uma assinatura do Azure fornecendo gerenciamento de acesso refinado para o Azure. O RBAC do Azure permite que você segregue tarefas dentro de sua organização e conceda acesso com base no que os usuários precisam para executar seus trabalhos. Em vez de conceder a todos permissões irrestritas na assinatura ou recursos do Azure, você pode permitir apenas determinadas ações.

O RBAC do Azure tem três funções básicas que se aplicam a todos os tipos de recursos:

• O proprietário tem acesso total a todos os recursos, incluindo o direito de delegar acesso a outros.

• O Colaborador pode criar e gerenciar todos os tipos de recursos do Azure, mas não pode conceder acesso a outros.

• O Reader pode exibir recursos existentes do Azure.

O restante das funções do Azure no Azure permite o gerenciamento de recursos específicos do Azure. Por exemplo, a função Contribuidor de Máquina Virtual permite ao utilizador criar e gerir máquinas virtuais. Ele não lhes dá acesso à Rede Virtual do Azure ou à sub-rede à qual a máquina virtual se conecta.

As funções internas do Azure listam as funções disponíveis no Azure. Ele especifica as operações e o escopo que cada função interna concede aos usuários. Se você estiver procurando definir suas próprias funções para obter ainda mais controle, veja como criar funções personalizadas no Azure RBAC.

Alguns outros recursos para o Microsoft Entra ID incluem:

• O Microsoft Entra ID permite o SSO para aplicativos SaaS, independentemente de onde eles estão hospedados. Alguns aplicativos são federados com o Microsoft Entra ID e outros usam SSO de senha. Os aplicativos federados também podem oferecer suporte ao provisionamento de usuários e ao cofre de senhas.

• O acesso aos dados do Armazenamento do Azure é controlado através da autenticação. Cada conta de armazenamento tem uma chave primária (chave de conta de armazenamento ou SAK) e uma chave secreta secundária (a assinatura de acesso compartilhado ou SAS).

• O Microsoft Entra ID fornece Identidade como Serviço por meio de federação usando os Serviços de Federação do Ative Directory, sincronização e replicação com diretórios locais.

• A autenticação multifator do Microsoft Entra exige que os usuários verifiquem as entradas usando um aplicativo móvel, chamada telefônica ou mensagem de texto. Ele pode ser usado com o Microsoft Entra ID para ajudar a proteger recursos locais com o Multi-Factor Authentication Server e também com aplicativos e diretórios personalizados usando o SDK.

• Os Serviços de Domínio Microsoft Entra permitem associar máquinas virtuais do Azure a um domínio do Ative Directory sem implantar controladores de domínio. Você pode entrar nessas máquinas virtuais com suas credenciais corporativas do Ative Directory e administrar máquinas virtuais ingressadas no domínio usando a Política de Grupo para impor linhas de base de segurança em todas as suas máquinas virtuais do Azure.

• O Azure Ative Directory B2C fornece um serviço de gerenciamento de identidade global altamente disponível para aplicativos voltados para o consumidor que pode ser dimensionado para centenas de milhões de identidades. Pode ser integrado entre plataformas móveis e Web. Seus consumidores podem entrar em todos os seus aplicativos por meio de experiências personalizáveis usando suas contas sociais existentes ou criando credenciais.

Isolamento de administradores da Microsoft & exclusão de dados

A Microsoft toma medidas rigorosas para proteger os seus dados contra acesso ou utilização inadequados por pessoas não autorizadas. Esses processos e controles operacionais são respaldados pelos Termos de Serviços Online, que oferecem compromissos contratuais que regem o acesso aos seus dados.

• Os engenheiros da Microsoft não têm acesso padrão aos seus dados na nuvem. Em vez disso, eles recebem acesso, sob supervisão do gerenciamento, apenas quando necessário. Esse acesso é cuidadosamente controlado e registrado, e revogado quando não é mais necessário.
• A Microsoft pode contratar outras empresas para fornecer serviços limitados em seu nome. Os subcontratados podem acessar os dados do cliente apenas para fornecer os serviços para os quais nós os contratamos para fornecer, e eles estão proibidos de usá-los para qualquer outra finalidade. Além disso, eles estão contratualmente obrigados a manter a confidencialidade das informações de nossos clientes.

Os serviços empresariais com certificações auditadas, como a ISO/IEC 27001, são regularmente verificados pela Microsoft e por empresas de auditoria acreditadas, que realizam auditorias de amostra para atestar esse acesso, apenas para fins comerciais legítimos. Pode sempre aceder aos seus próprios dados de cliente a qualquer momento e por qualquer motivo.

Se você excluir quaisquer dados, o Microsoft Azure excluirá os dados, incluindo quaisquer cópias em cache ou de backup. Para serviços dentro do escopo, essa exclusão ocorrerá dentro de 90 dias após o final do período de retenção. (Os serviços no âmbito são definidos na secção Termos de Processamento de Dados do nosso Termos dos Serviços Online.)

Se uma unidade de disco usada para armazenamento sofrer uma falha de hardware, ela será apagada ou destruída com segurança antes que a Microsoft a devolva ao fabricante para substituição ou reparo. Os dados na unidade são substituídos para garantir que os dados não possam ser recuperados por qualquer meio.

Isolamento de computação

O Microsoft Azure fornece vários serviços de computação baseados em nuvem que incluem uma ampla seleção de instâncias de computação e serviços que podem ser dimensionados automaticamente para atender às necessidades de seu aplicativo ou empresa. Essas instâncias e serviços de computação oferecem isolamento em vários níveis para proteger os dados sem sacrificar a flexibilidade de configuração exigida pelos clientes.

Tamanhos isolados de máquinas virtuais

A Computação do Azure oferece tamanhos de máquinas virtuais que são Isolados para um tipo de hardware específico e dedicados a um único cliente. Os tamanhos isolados vivem e operam em geração de hardware específica e serão preteridos quando a geração de hardware for desativada ou a nova geração de hardware estiver disponível.

Os tamanhos de máquinas virtuais isoladas são mais adequados para cargas de trabalho que exigem um alto grau de isolamento das cargas de trabalho de outros clientes. Às vezes, isso é necessário para atender aos requisitos de conformidade e regulamentares. A utilização de um tamanho isolado garante que sua máquina virtual seja a única em execução nessa instância específica do servidor.

Além disso, como as VMs de tamanho isolado são grandes, os clientes podem optar por subdividir os recursos dessas VMs usando o suporte do Azure para máquinas virtuais aninhadas.

As ofertas atuais de máquinas virtuais isoladas incluem:

• Standard_E80ids_v4
• Standard_E80is_v4
• Standard_E104i_v5
• Standard_E104is_v5
• Standard_E104id_v5
• Standard_E104ids_v5
• Standard_M192is_v2
• Standard_M192ims_v2
• Standard_M192ids_v2
• Standard_M192idms_v2
• Standard_F72s_v2
• Standard_M128ms

Descontinuação de tamanhos de VM isolados

Os tamanhos de VM isolados têm uma vida útil limitada pelo hardware. O Azure emite lembretes 12 meses antes da data oficial de descontinuação dos tamanhos e fornece uma oferta isolada atualizada para sua consideração. Os seguintes tamanhos têm aposentadoria anunciada.

Tamanho	Data de Aposentadoria de Isolamento
Standard_DS15_v2	15 de maio de 2021
Standard_D15_v2	15 de maio de 2021
Standard_G5	15 de fevereiro de 2022
Standard_GS5	15 de fevereiro de 2022
Standard_E64i_v3	15 de fevereiro de 2022
Standard_E64is_v3	15 de fevereiro de 2022
Standard_M192is_v2	Março 31, 2027
Standard_M192ims_v2	Março 31, 2027
Standard_M192ids_v2	Março 31, 2027
Standard_M192idms_v2	Março 31, 2027

FAQ

P: O tamanho vai ser aposentado ou apenas seu recurso de "isolamento"?

R: Qualquer tamanho que seja publicado como isolado, mas não tenha "i" no nome, o recurso de isolamento dos tamanhos de VM está sendo desativado, a menos que seja comunicado de forma diferente. Os tamanhos com "i" no nome serão preteridos.

P: Existe um tempo de inatividade quando minha vm pousa em um hardware não isolado?

R: Para tamanhos de VM, onde apenas o isolamento é preterido, mas não o tamanho, nenhuma ação é necessária e não haverá tempo de inatividade. Pelo contrário, se o isolamento for necessário, o anúncio inclui o tamanho de substituição recomendado. A seleção do tamanho de substituição exige que os clientes redimensionem suas VMs.

P: Existe algum delta de custo para mudar para uma máquina virtual não isolada?

R: Não

P: Quando é que os outros tamanhos isolados vão reformar-se?

R: Nós fornecemos lembretes com 12 meses de antecedência da depreciação oficial do tamanho isolado. Nosso anúncio mais recente inclui a aposentadoria do recurso de isolamento de Standard_G5, Standard_GS5, Standard_E64i_v3 e Standard_E64i_v3.

P: Sou um cliente do Azure Service Fabric que depende dos níveis de durabilidade Silver ou Gold. Essa mudança me impacta?

R: Não. As garantias fornecidas pelos Níveis de Durabilidade do Service Fabric continuarão a funcionar mesmo após esta alteração. Se você precisar de isolamento de hardware físico por outros motivos, talvez ainda seja necessário executar uma das ações descritas acima.

P: Quais são os marcos para D15_v2 ou DS15_v2 aposentadoria isolada?

A:

Date	Ação
15 de maio de 20201	D/DS15_v2 anúncio de aposentadoria por isolamento
15 de maio de 2021	Garantia de isolamento D/DS15_v2 removida

1 O cliente existente que usar esses tamanhos receberá um e-mail de anúncio com instruções detalhadas sobre as próximas etapas.

P: Quais são os marcos para G5, Gs5, E64i_v3 e E64is_v3 aposentadoria de isolamento?

A:

Date	Ação
Fev 15, 20211	Anúncio de aposentadoria de isolamento G5/GS5/E64i_v3/E64is_v3
Fev 28, 2022	Garantia de isolamento G5/GS5/E64i_v3/E64is_v3 removida

1 O cliente existente que usar esses tamanhos receberá um e-mail de anúncio com instruções detalhadas sobre as próximas etapas.

Próximos passos

Os clientes também podem optar por subdividir ainda mais os recursos dessas máquinas virtuais isoladas usando o suporte do Azure para máquinas virtuais aninhadas.

Anfitriões dedicados

Além dos hosts isolados descritos na seção anterior, o Azure também oferece hosts dedicados. Hosts dedicados no Azure é um serviço que fornece servidores físicos que podem hospedar uma ou mais máquinas virtuais e que são dedicados a uma única assinatura do Azure. Os hosts dedicados fornecem isolamento de hardware no nível do servidor físico. Nenhuma outra VM será colocada nos seus anfitriões. Os hosts dedicados são implantados nos mesmos datacenters e compartilham a mesma rede e a mesma infraestrutura de armazenamento subjacente que outros hosts não isolados. Para obter mais informações, consulte a visão geral detalhada dos hosts dedicados do Azure.

Hyper-V & Isolamento do SO raiz entre VM raiz & VMs convidadas

A plataforma de computação do Azure é baseada na virtualização de máquina, o que significa que todo o código do cliente é executado em uma máquina virtual Hyper-V. Em cada nó do Azure (ou ponto de extremidade de rede), há um Hipervisor que é executado diretamente sobre o hardware e divide um nó em um número variável de Máquinas Virtuais Convidadas (VMs).

Cada nó também tem uma VM raiz especial, que executa o sistema operacional host. Um limite crítico é o isolamento da VM raiz das VMs convidadas e das VMs convidadas uma da outra, gerenciadas pelo hipervisor e pelo sistema operacional raiz. O emparelhamento hipervisor/sistema operacional raiz aproveita as décadas de experiência em segurança do sistema operacional da Microsoft e o aprendizado mais recente do Hyper-V da Microsoft para fornecer um forte isolamento de VMs convidadas.

A plataforma Azure utiliza um ambiente virtualizado. As instâncias de usuário operam como máquinas virtuais autônomas que não têm acesso a um servidor host físico.

O hipervisor do Azure age como um microkernel e passa todas as solicitações de acesso de hardware de máquinas virtuais convidadas para o host para processamento usando uma interface de memória compartilhada chamada VM Bus. Isto impede os utilizadores de obterem acesso de leitura/escrita/execução não processado ao sistema e atenua o risco de partilha de recursos do sistema.

Algoritmo avançado de posicionamento de VM & proteção contra ataques de canal lateral

Qualquer ataque entre VMs envolve duas etapas: colocar uma VM controlada por adversários no mesmo host que uma das VMs vítimas e, em seguida, violar o limite de isolamento para roubar informações confidenciais da vítima ou afetar seu desempenho por ganância ou vandalismo. O Microsoft Azure fornece proteção em ambas as etapas usando um algoritmo avançado de posicionamento de VM e proteção contra todos os ataques de canal lateral conhecidos, incluindo VMs vizinhas barulhentas.

O Azure Fabric Controller

O Azure Fabric Controller é responsável por alocar recursos de infraestrutura para cargas de trabalho de locatário e gerencia comunicações unidirecionais do host para máquinas virtuais. O algoritmo de colocação de VM do controlador de malha do Azure é altamente sofisticado e quase impossível de prever como nível de host físico.

O hipervisor do Azure impõe a separação de memória e processo entre máquinas virtuais e roteia com segurança o tráfego de rede para locatários convidados do sistema operacional. Isso elimina a possibilidade de ataque de canal lateral no nível de VM.

No Azure, a VM raiz é especial: ela executa um sistema operacional protegido chamado sistema operacional raiz que hospeda um agente de malha (FA). Os FAs, por sua vez, são usados para gerenciar agentes convidados (GA) em sistemas operacionais convidados em VMs de clientes. As FAs também gerenciam nós de armazenamento.

A coleção de hipervisor do Azure, SO/FA raiz e VMs/GAs do cliente compreende um nó de computação. Os FAs são gerenciados por um controlador de malha (FC), que existe fora dos nós de computação e armazenamento (clusters de computação e armazenamento são gerenciados por FCs separados). Se um cliente atualizar o arquivo de configuração do aplicativo enquanto ele estiver em execução, o FC se comunicará com o FA, que entrará em contato com os GAs, que notificarão o aplicativo sobre a alteração de configuração. No caso de uma falha de hardware, o FC encontrará automaticamente o hardware disponível e reiniciará a VM lá.

A comunicação de um controlador de malha para um agente é unidirecional. O agente implementa um serviço protegido por SSL que só responde a solicitações do controlador. Ele não pode iniciar conexões com o controlador ou outros nós internos privilegiados. A CF trata todas as respostas como se não fossem confiáveis.

O isolamento se estende da VM raiz das VMs convidadas e das VMs convidadas umas das outras. Os nós de computação também são isolados dos nós de armazenamento para maior proteção.

O hipervisor e o sistema operacional host fornecem pacotes de rede - filtros para ajudar a garantir que máquinas virtuais não confiáveis não possam gerar tráfego falsificado ou receber tráfego não endereçado a elas, direcionar tráfego para pontos de extremidade de infraestrutura protegidos ou enviar/receber tráfego de difusão inadequado.

Regras adicionais configuradas pelo Fabric Controller Agent para isolar a VM

Por padrão, todo o tráfego é bloqueado quando uma máquina virtual é criada e, em seguida, o agente do controlador de malha configura o filtro de pacotes para adicionar regras e exceções para permitir o tráfego autorizado.

Existem duas categorias de regras que são programadas:

• Configuração da máquina ou regras de infraestrutura: por padrão, toda a comunicação é bloqueada. Há exceções para permitir que uma máquina virtual envie e receba tráfego DHCP e DNS. As máquinas virtuais também podem enviar tráfego para a Internet "pública" e enviar tráfego para outras máquinas virtuais dentro da mesma Rede Virtual do Azure e do servidor de ativação do SO. A lista de destinos de saída permitidos das máquinas virtuais não inclui sub-redes do roteador do Azure, gerenciamento do Azure e outras propriedades da Microsoft.
• Arquivo de configuração de função: define as ACLs (Listas de Controle de Acesso) de entrada com base no modelo de serviço do locatário.

Isolamento de VLAN

Há três VLANs em cada cluster:

• A VLAN principal – interconecta nós de clientes não confiáveis
• A FC VLAN – contém FCs confiáveis e sistemas de suporte
• A VLAN do dispositivo – contém dispositivos de rede confiáveis e outros dispositivos de infraestrutura

A comunicação é permitida da VLAN FC para a VLAN principal, mas não pode ser iniciada da VLAN principal para a VLAN FC. A comunicação também é bloqueada da VLAN principal para a VLAN do dispositivo. Isso garante que, mesmo que um nó que executa o código do cliente seja comprometido, ele não pode atacar nós na FC ou nas VLANs do dispositivo.

Isolamento de armazenamento

Isolamento lógico entre computação e armazenamento

Como parte de seu design fundamental, o Microsoft Azure separa a computação baseada em VM do armazenamento. Essa separação permite que a computação e o armazenamento sejam dimensionados de forma independente, facilitando o fornecimento de multilocação e isolamento.

Portanto, o Armazenamento do Azure é executado em hardware separado sem conectividade de rede com o Azure Compute, exceto logicamente. Isso significa que, quando um disco virtual é criado, o espaço em disco não é alocado para toda a sua capacidade. Em vez disso, é criada uma tabela que mapeia endereços no disco virtual para áreas no disco físico e essa tabela está inicialmente vazia. Na primeira vez que um cliente grava dados no disco virtual, o espaço no disco físico é alocado e um ponteiro para ele é colocado na tabela.

Isolamento usando o controle de acesso ao armazenamento

O Controle de Acesso no Armazenamento do Azure tem um modelo de controle de acesso simples. Cada assinatura do Azure pode criar uma ou mais Contas de Armazenamento. Cada Conta de Armazenamento tem uma única chave secreta que é usada para controlar o acesso a todos os dados nessa Conta de Armazenamento.

O acesso aos dados do Armazenamento do Azure (incluindo Tabelas) pode ser controlado por meio de um token SAS (Assinatura de Acesso Compartilhado), que concede acesso com escopo. A SAS é criada através de um modelo de consulta (URL), assinado com a SAK (Storage Account Key). Essa URL assinada pode ser dada a outro processo (ou seja, delegado), que pode preencher os detalhes da consulta e fazer a solicitação do serviço de armazenamento. Uma SAS permite que você conceda acesso baseado em tempo aos clientes sem revelar a chave secreta da conta de armazenamento.

O SAS significa que podemos conceder a um cliente permissões limitadas para objetos em nossa conta de armazenamento por um período de tempo especificado e com um conjunto especificado de permissões. Podemos conceder essas permissões limitadas sem ter que compartilhar as chaves de acesso da sua conta.

Isolamento de armazenamento em nível IP

Você pode estabelecer firewalls e definir um intervalo de endereços IP para seus clientes confiáveis. Com um intervalo de endereços IP, apenas os clientes que têm um endereço IP dentro do intervalo definido podem se conectar ao Armazenamento do Azure.

Os dados de armazenamento IP podem ser protegidos contra usuários não autorizados por meio de um mecanismo de rede usado para alocar um túnel dedicado ou dedicado de tráfego para armazenamento IP.

Encriptação

O Azure oferece os seguintes tipos de Criptografia para proteger dados:

• Encriptação em trânsito
• Encriptação inativa

Encriptação em Trânsito

A encriptação em trânsito é um mecanismo de proteção de dados quando estes são transmitidos através de redes. Com o Armazenamento do Azure, você pode proteger os dados usando:

• Criptografia no nível de transporte, como HTTPS quando você transfere dados para dentro ou para fora do Armazenamento do Azure.
• Criptografia de fio, como a criptografia SMB 3.0 para compartilhamentos de arquivos do Azure.
• Criptografia do lado do cliente, para criptografar os dados antes de serem transferidos para o armazenamento e para descriptografar os dados depois de serem transferidos para fora do armazenamento.

Encriptação Inativa

Para muitas organizações, a criptografia de dados em repouso é um passo obrigatório para a privacidade, conformidade e soberania de dados. Há três recursos do Azure que fornecem criptografia de dados que estão "em repouso":

• A Criptografia do Serviço de Armazenamento permite que você solicite que o serviço de armazenamento criptografe automaticamente os dados ao gravá-los no Armazenamento do Azure.
• A criptografia do lado do cliente também fornece o recurso de criptografia em repouso.
• Azure Disk Encryption para VMs Linux e Azure Disk Encryption para VMs Windows.

Para obter mais informações, consulte Visão geral das opções de criptografia de disco gerenciado.

Azure Disk Encryption

O Azure Disk Encryption para VMs Linux e o Azure Disk Encryption para VMs Windows ajudam você a atender aos requisitos organizacionais de segurança e conformidade criptografando seus discos de VM (incluindo discos de inicialização e de dados) com chaves e políticas que você controla no Cofre de Chaves do Azure.

A solução de Encriptação de Disco para Windows baseia-se na Encriptação de Unidade BitLocker da Microsoft e a solução Linux baseia-se em dm-crypt.

A solução oferece suporte aos seguintes cenários para VMs IaaS quando elas são habilitadas no Microsoft Azure:

• Integração com o Azure Key Vault
• VMs de camada padrão: A, D, DS, G, GS e assim por diante, VMs IaaS da série
• Habilitando a criptografia em VMs IaaS Windows e Linux
• Desativando a criptografia no sistema operacional e unidades de dados para VMs IaaS do Windows
• Desativando a criptografia em unidades de dados para VMs IaaS Linux
• Habilitando a criptografia em VMs IaaS que executam o sistema operacional cliente Windows
• Habilitando a criptografia em volumes com caminhos de montagem
• Habilitando a criptografia em VMs Linux configuradas com striping de disco (RAID) usando mdadm
• Habilitando a criptografia em VMs Linux usando LVM (Logical Volume Manager) para discos de dados
• Habilitando a criptografia em VMs do Windows configuradas usando espaços de armazenamento
• Todas as regiões públicas do Azure são suportadas

A solução não suporta os seguintes cenários, recursos e tecnologia na versão:

• VMs IaaS de camada básica
• Desativando a criptografia em uma unidade de sistema operacional para VMs IaaS Linux
• VMs IaaS que são criadas usando o método clássico de criação de VM
• Integração com seu Serviço de Gerenciamento de Chaves local
• Arquivos do Azure (sistema de arquivos compartilhado), NFS (Network File System), volumes dinâmicos e VMs do Windows configurados com sistemas RAID baseados em software

Isolamento do Banco de Dados SQL

A Base de Dados SQL é um serviço de bases de dados relacionais na cloud da Microsoft baseado no motor Microsoft SQL Server líder de mercado e com capacidade para processar cargas de trabalho críticas para missões. O Banco de dados SQL oferece isolamento de dados previsível em nível de conta, geografia/região e com base em rede, tudo com administração quase nula.

Modelo de Aplicativo do Banco de Dados SQL

O Banco de Dados Microsoft SQL é um serviço de banco de dados relacional baseado em nuvem criado em tecnologias SQL Server. Ele fornece um serviço de banco de dados altamente disponível, escalável e multilocatário hospedado pela Microsoft na nuvem.

Do ponto de vista do aplicativo, o Banco de dados SQL fornece a seguinte hierarquia: Cada nível tem uma contenção de um para muitos de níveis abaixo.

A conta e a subscrição são conceitos da plataforma Microsoft Azure para associar faturação e gestão.

Servidores SQL lógicos e bancos de dados são conceitos específicos do Banco de Dados SQL e são gerenciados usando o Banco de Dados SQL, interfaces OData e TSQL fornecidas ou por meio do portal do Azure.

Os servidores no Banco de dados SQL não são instâncias físicas ou VM, em vez disso, são coleções de bancos de dados, gerenciamento de compartilhamento e políticas de segurança, que são armazenados no chamado banco de dados "mestre lógico".

Os bancos de dados mestres lógicos incluem:

• Logons SQL usados para se conectar ao servidor
• Regras da firewall

Não é garantido que as informações relacionadas à cobrança e ao uso de bancos de dados do mesmo servidor estejam na mesma instância física no cluster, em vez disso, os aplicativos devem fornecer o nome do banco de dados de destino ao se conectar.

Do ponto de vista do cliente, um servidor é criado em uma região geográfica, enquanto a criação real do servidor acontece em um dos clusters da região.

Isolamento através da topologia de rede

Quando um servidor é criado e seu nome DNS é registrado, o nome DNS aponta para o chamado endereço "Gateway VIP" no data center específico onde o servidor foi colocado.

Por trás do VIP (endereço IP virtual), temos uma coleção de serviços de gateway sem estado. Em geral, os gateways se envolvem quando há coordenação necessária entre várias fontes de dados (banco de dados mestre, banco de dados de usuários, etc.). Os serviços de gateway implementam o seguinte:

• Proxy de conexão TDS. Isso inclui localizar o banco de dados do usuário no cluster de back-end, implementar a sequência de login e, em seguida, encaminhar os pacotes TDS para o back-end e vice-versa.
• Gestão de bases de dados. Isso inclui a implementação de uma coleção de fluxos de trabalho para fazer operações de banco de dados CREATE/ALTER/DROP. As operações de banco de dados podem ser invocadas detetando pacotes TDS ou APIs OData explícitas.
• Operações de login/utilizador CREATE/ALTER/DROP
• Operações de gerenciamento de servidor via API OData

A camada por trás dos gateways é chamada de "back-end". É aqui que todos os dados são armazenados de forma altamente disponível. Diz-se que cada pedaço de dados pertence a uma "partição" ou "unidade de failover", cada um deles tendo pelo menos três réplicas. As réplicas são armazenadas e replicadas pelo mecanismo do SQL Server e gerenciadas por um sistema de failover, geralmente chamado de "malha".

Geralmente, o sistema back-end não comunica a saída para outros sistemas como precaução de segurança. Isso é reservado para os sistemas na camada front-end (gateway). As máquinas de camada de gateway têm privilégios limitados nas máquinas back-end para minimizar a superfície de ataque como um mecanismo de defesa profunda.

Isolamento por Função e Acesso à Máquina

O Banco de dados SQL é composto por serviços executados em diferentes funções da máquina. O Banco de Dados SQL é dividido em ambientes de "backend" Cloud Database e "front-end" (Gateway/Management), com o princípio geral de tráfego entrando apenas no back-end e não saindo. O ambiente front-end pode se comunicar com o mundo externo de outros serviços e, em geral, tem apenas permissões limitadas no back-end (o suficiente para chamar os pontos de entrada que precisa invocar).

Isolamento de rede

A implantação do Azure tem várias camadas de isolamento de rede. O diagrama a seguir mostra várias camadas de isolamento de rede que o Azure fornece aos clientes. Essas camadas são nativas na própria plataforma Azure e recursos definidos pelo cliente. Entrada da Internet, o Azure DDoS fornece isolamento contra ataques em grande escala contra o Azure. A próxima camada de isolamento são os endereços IP públicos definidos pelo cliente (pontos de extremidade), que são usados para determinar qual tráfego pode passar pelo serviço de nuvem para a rede virtual. O isolamento de rede virtual nativo do Azure garante o isolamento completo de todas as outras redes e que o tráfego flui apenas através de caminhos e métodos configurados pelo usuário. Esses caminhos e métodos são a próxima camada, onde NSGs, UDR e dispositivos virtuais de rede podem ser usados para criar limites de isolamento para proteger as implantações de aplicativos na rede protegida.

Isolamento de tráfego: uma rede virtual é o limite de isolamento de tráfego na plataforma Azure. As máquinas virtuais (VMs) em uma rede virtual não podem se comunicar diretamente com VMs em uma rede virtual diferente, mesmo que ambas as redes virtuais sejam criadas pelo mesmo cliente. O isolamento é uma propriedade crítica que garante que as VMs e a comunicação do cliente permaneçam privadas em uma rede virtual.

A sub-rede oferece uma camada adicional de isolamento com uma rede virtual baseada no intervalo de IP. Endereços IP na rede virtual, você pode dividir uma rede virtual em várias sub-redes para organização e segurança. As VMs e as instâncias de função de PaaS implementadas em sub-redes (nas mesmas ou em diferentes) dentro de uma VNet podem comunicar entre si sem qualquer configuração adicional. Você também pode configurar NSGs (grupo de segurança de rede) para permitir ou negar tráfego de rede para uma instância de VM com base em regras configuradas na lista de controle de acesso (ACL) do NSG. Os NSGs podem ser associados a sub-redes ou a instâncias de VM individuais dentro dessa sub-rede. Quando um NSG é associado a uma sub-rede, as regras da ACL são aplicadas a todas as instâncias de VM nessa sub-rede.

Passos Seguintes

• Saiba mais sobre as Opções de Isolamento de Rede para Máquinas em Redes Virtuais do Windows Azure. Isso inclui o cenário clássico de front-end e back-end, em que as máquinas em uma determinada rede ou sub-rede back-end só podem permitir que determinados clientes ou outros computadores se conectem a um ponto de extremidade específico com base em uma lista de endereços IP permitidos.

• Saiba mais sobre o isolamento de máquinas virtuais no Azure. O Azure Compute oferece tamanhos de máquinas virtuais que são isolados para um tipo de hardware específico e dedicados a um único cliente.