Considerações sobre rede do Arquivos do Azure

✔️ Aplica-se a: Todos os compartilhamentos de arquivos do Azure

Compartilhamentos de arquivos do Azure possuem endpoints públicos e podem ter um ou mais endpoints privados. Os caminhos de rede disponíveis para os clientes dependem do protocolo e das regras de rede. Este artigo aborda tanto os compartilhamentos clássicos de arquivos (Microsoft.Storage) quanto os compartilhamentos de arquivos criados com Microsoft.FileShares. Sincronização de Arquivos do Azure oferece uma opção de cache para compartilhamentos clássicos de arquivos SMB. Para saber mais, consulte Introduction to Sincronização de Arquivos do Azure.

Para considerações mais amplas sobre implantação, veja Planeje uma implantação no Arquivos do Azure. Para as etapas de configuração, veja Configurar endpoints de rede para compartilhamentos de arquivos do Azure.

Duas diferenças de protocolo afetam o design da rede:

• A SMB utiliza a porta TCP 445, que algumas organizações e provedores de internet bloqueiam para tráfego de saída. Conectividade privada via VPN ou ExpressRoute oferece um caminho alternativo.

• O NFS utiliza autenticação baseada em rede. Os clientes se conectam por meio de endpoints privados ou de endpoints de serviço a partir de sub-redes de rede virtual permitidas.

Compartilhamentos de arquivos clássicos suportam SMB e NFS. Microsoft. FileShares atualmente suporta NFS. Ambos os provedores de recursos suportam endpoints públicos e privados. Para diferenças na propriedade e gestão de recursos, veja conceitos de gerenciamento do Arquivos do Azure.

Criptografia em trânsito

A criptografia em trânsito protege a confidencialidade e a integridade dos dados entre clientes e o Arquivos do Azure, incluindo proteção contra interceptação ou modificação por um atacante man-in-the-middle. Essa proteção se aplica tanto a endpoints públicos quanto privados. As regras de criptografia e de acesso à rede têm propósitos separados: a criptografia protege a conexão, enquanto as regras de rede determinam quais clientes podem acessar o serviço.

Criptografia em trânsito para SMB

SMB 3.x protege dados por meio de criptografia de canal SMB. Arquivos do Azure suporta AES-128-CCM com SMB 3.0, e AES-128-GCM e AES-256-GCM com SMB 3.1.1. O algoritmo de criptografia depende das capacidades do cliente e dos algoritmos permitidos pelo serviço. SMB 2.1 não suporta criptografia de canais.

Restringir os algoritmos permitidos pode afetar a compatibilidade do cliente. Por exemplo, clientes Windows mais antigos não suportam AES-256-GCM. A criptografia de canal protege os dados dos arquivos na conexão; A criptografia de tickets Kerberos protege os tickets de autenticação. São controles separados. Para suporte a clientes e configuração, veja configurações de segurança SMB.

Criptografia em trânsito para NFS

Compartilhamentos de arquivos NFS com um ou outro provedor de recursos oferecem suporte à criptografia por meio de túnel TLS. O helper de montagem do AZNFS usa o stunnel para transportar tráfego NFS através de uma conexão criptografada entre o cliente e o Arquivos do Azure. O AZNFS suporta TLS 1.2 e TLS 1.3 e valida o certificado do servidor. As aplicações continuam a usar o protocolo NFS sem implementar o TLS por conta própria.

O TLS protege os dados em trânsito, mas não adiciona autenticação baseada no usuário ao NFS. Regras de acesso à rede e permissões de arquivo ainda governam o acesso. Para instruções para montagem criptografada, veja Criptografar dados em trânsito para compartilhamentos NFS.

Criptografia em trânsito para FileREST

O FileREST protege dados em trânsito via HTTPS. Arquivos do Azure suporta TLS 1.2 e TLS 1.3 para conexões HTTPS. Exigir HTTPS rejeita requisições HTTP não criptografadas; um requisito mínimo de versão TLS determina quais versões TLS os clientes podem usar.

O acesso a dados FileREST está disponível para compartilhamentos de arquivos clássicos. Microsoft.FileShares atualmente não suporta acesso a dados FileREST.

Guias de configuração de criptografia

Os requisitos e as configurações padrão de criptografia dependem do provedor de recurso e do protocolo. Os guias a seguir descrevem como visualizá-los e alterá-los:

• Microsoft.FileShares: Requisitos de criptografia ao criar um compartilhamento de arquivos e atualizar propriedades de compartilhamento de arquivos com PowerShell ou CLI do Azure.
• Compartilhamentos clássicos de arquivos: criptografia SMB, criptografia NFS e requisitos HTTPS para FileREST.

Ponto de extremidade público

Um endpoint público tem um endereço IP público. Um endereço público não implica acesso irrestrito: requisitos de protocolo, regras de rede e autorização determinam se uma solicitação é permitida.

Os protocolos possuem regras diferentes para acesso a endpoints públicos. SMB e FileREST se aplicam a compartilhamentos de arquivos clássicos. O NFS se aplica a ambos os provedores de recursos:

• SMB: Conexões SMB 3.x criptografadas podem se originar dentro ou fora do Azure, sujeitas às regras de rede e autorização. Conexões SMB não criptografadas são limitadas a clientes na mesma região do Azure e exigem uma configuração que permita acesso não criptografado.

• NFS: Os clientes só podem acessar o endpoint público por meio de um endpoint de serviço a partir de uma sub-rede permitida. O NFS não suporta acesso direto por clientes na Internet.

• FileREST: Clientes acessam os dados dos arquivos por meio de requisições REST. O HTTPS protege essas requisições em trânsito. Regras de rede e autorização se aplicam independentemente de HTTPS ser necessário ou não.

Acesso à rede de entrada

Regras de rede controlam o acesso de entrada ao endpoint público. Ambos os provedores de recursos suportam acesso a partir de sub-redes selecionadas da rede virtual. O acesso clássico SMB e FileREST também pode usar regras de endereço IP. O acesso NFS requer endpoints de serviço e sub-redes permitidas.

Um endpoint de serviço transporta tráfego de uma sub-rede virtual para o Arquivos do Azure através da backbone do Azure. O tráfego ainda usa o endereço IP do endpoint público. A camada de rede identifica a sub-rede de origem para que o serviço possa compará-la às redes permitidas.

Desabilitar o acesso à rede pública também impede o acesso do cliente através dos endpoints de serviço. O acesso a endpoints privados é independente dessa configuração. Para compartilhamentos clássicos de arquivos, exceções de serviço confiável existentes podem permanecer em vigor.

Para etapas de configuração para ambos os provedores de recursos, veja Restringir acesso ao endpoint público.

Restringir o acesso de saída com políticas de endpoint de serviço

Regras de rede para compartilhamento de arquivos controlam o acesso de entrada. Eles não restringem os destinos de saída dos clientes. Por exemplo, um cliente que pode ler um compartilhamento de arquivos pode copiar dados para outro recurso ao qual tenha permissão de gravação.

Para compartilhamentos clássicos de arquivos, você pode opcionalmente usar uma política de endpoint de serviço para limitar quais contas de armazenamento os clientes em uma sub-rede podem acessar através de endpoints de serviço. A política se aplica a todos os clientes dessa sub-rede. As regras de rede e os requisitos de autorização do destino ainda se aplicam.

As políticas de endpoint de serviço funcionam junto com outros controles de rede:

• Rotas de endpoints de serviço substituem rotas definidas pelo usuário (UDRs) para os prefixos de endereço de serviço correspondentes. O tráfego roteado por um endpoint de serviço não passa pelo Firewall do Azure ou por um appliance virtual de rede (NVA), então esses dispositivos não podem inspecioná-lo ou registrá-lo em log. Para obter mais informações, consulte Pontos de extremidade de serviço de rede virtual.
• As regras do NSG (grupo de segurança de rede) podem usar marcas de serviço, como Storage.WestUS, para restringir o tráfego de saída a uma região. As etiquetas de serviço não podem restringir o tráfego a uma conta de armazenamento específica.

A lista de permissão da política pode conter contas individuais de armazenamento, grupos de recursos ou assinaturas. A política bloqueia clientes na sub-rede associada de acessarem outras contas de armazenamento por meio de endpoints de serviço. Ela não restringe outros caminhos de saída da sub-rede.

Políticas de endpoint de serviço não se aplicam ao tráfego de endpoints privados.

Para configurar uma política de endpoint de serviço, veja Restringir acesso de saída a contas de armazenamento específicas.

Acesso ao portal do Azure

Abrir um recurso no portal do Azure e acessar seus dados de arquivo são operações separadas. Para compartilhamentos clássicos de arquivos, navegar pelos dados envia requisições FileREST do navegador para o endpoint do serviço de arquivos. Essas solicitações estão sujeitas às regras de rede da conta de armazenamento. O acesso ao portal sozinho não garante acesso à rede aos dados dos arquivos.

Microsoft.FileShares atualmente não suporta acesso a dados FileREST. Para requisitos clássicos de navegação por compartilhamento de arquivos e solução de problemas, veja Autorizar acesso a dados de arquivos no portal Azure.

Roteamento de rede de ponto de extremidade público

A preferência de roteamento está disponível apenas para compartilhamentos clássicos de arquivos HDD que utilizam o modelo de faturamento pay-as-you-go em StorageV2 contas de armazenamento. Ele não tem suporte para compartilhamentos de arquivos provisionados em contas de armazenamento FileStorage nem para Microsoft.FileShares.

Para essas contas pay-as-you-go, a preferência de roteamento determina como o tráfego de internet chega ao endpoint público:

• Roteamento da Microsoft (padrão): O tráfego entre o cliente e a conta de armazenamento trafega pela rede de backbone global da Microsoft pelo maior tempo possível antes de sair para a Internet. Essa opção oferece suporte a cenários de ingresso no domínio do Active Directory (AD) e ao Sincronização de Arquivos do Azure.
• Roteamento da Internet: O tráfego é roteado pela internet pública o mais cedo possível. Essa opção não suporta cenários de junção de domínio no Active Directory (AD) nem no Sincronização de Arquivos do Azure.

Para ver as etapas de configuração, consulte Configurar preferência de roteamento de rede.

Pontos de extremidade privados

Um endpoint privado fornece um endereço IP privado na sua rede virtual para acesso a um compartilhamento de arquivos.

Cada endpoint privado está associado a uma sub-rede de uma rede virtual. Múltiplos endpoints privados podem fornecer acesso ao mesmo compartilhamento de arquivos a partir de diferentes redes virtuais.

Os clientes podem acessar um endpoint privado a partir de sua rede virtual, redes virtuais peered ou redes conectadas on-premiss.

Endpoints privados e públicos podem coexistir. Criar um endpoint privado não desativa o acesso público nem restringe outros caminhos de saída dos clientes.

Para criar um ponto de extremidade privado, consulte Configurando pontos de extremidade privados para Arquivos do Azure.

Conectividade privada a partir do ambiente local

VPN e ExpressRoute fornecem conectividade entre clientes locais e endpoints privados em uma rede virtual Azure. Essa abordagem se aplica tanto a SMB quanto a NFS.

As opções de conexão diferem em escopo e transporte:

VPN ponto a site

Uma VPN ponto a site conecta um cliente individual a uma rede virtual do Azure. Ele oferece suporte a usuários remotos e dispositivos que não estão conectados por meio de uma rede local da organização. Para protocolos com suporte e guias de configuração, consulte Sobre VPN ponto a site.

VPN de site a site

Uma VPN site-to-site conecta a rede de uma organização a uma rede virtual do Azure por meio de um gateway de VPN. Clientes na rede conectada compartilham essa conexão. Para guias de arquitetura e configuração, veja VPN Site-to-site.

ExpressRoute

O peering privado ExpressRoute conecta uma rede local a redes virtuais do Azure sem atravessar a internet pública. Ele oferece uma opção de conectividade privada para cargas de trabalho com desempenho de rede ou requisitos organizacionais. A criptografia em nível de aplicação continua sendo uma consideração separada. Para opções de conectividade e guias de configuração, veja a visão geral do ExpressRoute.

Resolução de DNS

O DNS determina se o nome de host de um compartilhamento de arquivos se resolve para um endereço IP público ou privado. Os clientes usam o mesmo nome de host para qualquer caminho. Dentro de uma rede que usa DNS privado para o compartilhamento, o nome se resolve para o endereço IP do endpoint privado. Clientes que usam DNS público resolvem para o endpoint público.

Compartilhamentos de arquivos clássicos usam o nome do host do serviço de arquivos da conta de armazenamento. Microsoft. FileShares atribui um nome de host gerado a cada compartilhamento de arquivos. Esse nome gerado é diferente do nome do recurso do compartilhamento de arquivos.

No Azure Public Cloud, ambos os provedores de recursos usam a zona DNS privada privatelink.file.core.windows.net. Clientes on-premises precisam de acesso aos registros DNS privados, bem como de uma rota de rede para o endpoint privado. Uma conexão VPN ou ExpressRoute sozinha não fornece resolução DNS privada. O encaminhamento DNS ou o DNS do Azure Private Resolver podem fornecer essa resolução.

Para configuração e verificação, veja:

• Crie um endpoint privado com integração DNS e verifique a conectividade, para ambos os provedores de recursos.
• Integração DNS de endpoint privado Azure, para projetos DNS on-premises.
• Configurar o encaminhamento de DNS para compartilhamentos clássicos de arquivos, para exemplos específicos do Arquivos do Azure.

SMB sobre QUIC

SMB sobre QUIC transporta tráfego SMB pela porta UDP 443, oferecendo uma alternativa quando a porta TCP 445 não está disponível. Um servidor de arquivos Windows Server compatível fornece o endpoint QUIC, e os clientes precisam de suporte SMB sobre QUIC.

Atualmente, o Arquivos do Azure não suporta SMB diretamente via QUIC. Você pode acessar um cache do Windows Server de um compartilhamento clássico de arquivos SMB através do Sincronização de Arquivos do Azure, conforme mostrado no diagrama a seguir. Essa opção não se aplica ao NFS ou ao Microsoft.FileShares. Você pode implantar caches do Sincronização de Arquivos do Azure localmente ou em datacenters do Azure. Para saber mais, consulte a documentação do Windows Server. Para detalhes específicos de rede do Sincronização de Arquivos do Azure, veja SMB sobre QUIC.

Consulte também

• visão geral Arquivos do Azure
• Plano para uma implantação de Arquivos do Azure