Compreender o estilo de segurança de protocolo duplo e os comportamentos de permissão nos Arquivos do Azure NetApp
SMB e NFS usam modelos de permissão diferentes para acesso de usuário e grupo. Como resultado, um volume de Arquivo do Azure NetApp deve ser configurado para honrar o modelo de permissão desejado para acesso ao protocolo. Para ambientes somente NFS, a decisão é simples – use estilos de segurança UNIX. Para ambientes somente SMB, use estilos de segurança NTFS.
Se NFS e SMB nos mesmos conjuntos de dados (protocolo duplo) forem necessários, a decisão deve ser tomada com base em duas perguntas:
- Qual protocolo os usuários gerenciarão mais as permissões?
- Qual é o ponto de extremidade de gerenciamento de permissões desejado? Em outras palavras, os usuários exigem a capacidade de gerenciar permissões de clientes NFS ou clientes Windows? Ou ambos?
Os estilos de segurança de volume podem realmente ser considerados estilos de permissão, onde o estilo desejado de gerenciamento de ACL é o fator decisivo.
Observação
Os estilos de segurança são escolhidos na criação do volume. Uma vez que o estilo de segurança foi escolhido, ele não pode ser alterado.
Sobre os estilos de segurança de volume do Azure NetApp Files
Há duas opções principais para estilos de segurança de volume nos Arquivos NetApp do Azure:
UNIX - O estilo de segurança UNIX fornece permissões no estilo UNIX, como bits básicos do modo POSIX (acesso Proprietário/Grupo/Todos com permissões padrão de Leitura/Gravação/Execução, como 0755) e ACLs NFSv4.x. As ACLs POSIX não são suportadas.
NTFS - O estilo de segurança NTFS fornece funcionalidade idêntica às permissões NTFS padrão do Windows, com usuários e grupos granulares em ACLs e permissões de segurança/auditoria detalhadas.
Em um ambiente NAS de protocolo duplo, apenas um estilo de permissão de segurança pode estar ativo. Você deve avaliar as considerações para cada estilo de segurança antes de escolher um.
| Estilo de segurança | Considerações |
|---|---|
| UNIX | - Os clientes Windows só podem definir atributos de permissão UNIX por meio de SMBs mapeados para atributos UNIX (somente leitura/gravação/execução; sem permissões especiais). - As ACLs NFSv4.x não possuem gerenciamento de GUI. O gerenciamento é feito somente via CLI usando nfs4_getfacl e comandos nfs4_setfacl. - Se um arquivo ou pasta tiver ACLs NFSv4.x, a guia Propriedades de segurança do Windows não poderá exibi-las. |
| NTFS | - Os clientes UNIX não podem definir atributos através do NFS através de comandos como chown/chmod. - Os clientes NFS mostram apenas permissões NTFS aproximadas ao usar ls comandos. Por exemplo, se um usuário tiver uma permissão em uma ACL NTFS do Windows que não pode ser convertida corretamente em um bit de modo POSIX (como diretório transversal), ela será convertida no valor de bit de modo POSIX mais próximo (como 1 para executar). |
A seleção do estilo de segurança de volume determina como o mapeamento de nome para um usuário é executado. Essa operação é a parte central de como os volumes de protocolo duplo mantêm permissões previsíveis, independentemente do protocolo em uso.
Use a tabela a seguir como uma matriz de decisão para selecionar os estilos de segurança de volume adequados.
| Estilo de segurança | Principalmente NFS | Principalmente SMB | Necessidade de segurança granular |
|---|---|---|---|
| UNIX | X | - | X (usando ACLs NFSv4.x) |
| NTFS | - | X | X |
Como o mapeamento de nome funciona nos Arquivos NetApp do Azure
Nos Arquivos do Azure NetApp, somente os usuários são autenticados e mapeados. Os grupos não são mapeados. Em vez disso, as associações de grupo são determinadas usando a identidade do usuário.
Quando um usuário tenta acessar um volume do Azure NetApp Files, essa tentativa passa uma identidade para o serviço. Essa identidade inclui um nome de usuário e um identificador numérico exclusivo (número UID para NFSv3, cadeia de caracteres de nome para NFSv4.1, SID para SMB). Os Arquivos NetApp do Azure usam essa identidade para autenticar em um serviço de nome configurado para verificar a identidade do usuário.
- A pesquisa LDAP por IDs numéricos é usada para procurar um nome de usuário no Active Directory.
- As cadeias de caracteres de nome usam a pesquisa LDAP para procurar um nome de usuário e o cliente e o servidor consultam o domínio de ID configurado para NFSv4.1 para garantir a correspondência.
- Os usuários do Windows são consultados usando chamadas RPC padrão do Windows para o Active Directory.
- As associações de grupo também são consultadas e tudo é adicionado a um cache de credenciais para processamento mais rápido em solicitações subsequentes ao volume.
- Atualmente, os usuários locais personalizados não têm suporte para uso com os Arquivos NetApp do Azure. Somente usuários no Active Directory podem ser usados com protocolos duplos.
- Atualmente, os únicos usuários locais que podem ser usados com volumes de protocolo duplo são o root e o
nfsnobodyusuário.
Depois que um nome de usuário é autenticado e validado pelos Arquivos NetApp do Azure, a próxima etapa para autenticação de volume de protocolo duplo é o mapeamento de nomes de usuário para interoperabilidade UNIX e Windows.
O estilo de segurança de um volume determina como um mapeamento de nome ocorre nos Arquivos do Azure NetApp. A semântica de permissões do Windows e do UNIX é diferente. Se um mapeamento de nome não puder ser executado, a autenticação falhará e o acesso a um volume de um cliente será negado. Um cenário comum em que essa situação ocorre é quando o acesso NFSv3 é tentado a um volume com estilo de segurança NTFS. A solicitação de acesso inicial do NFSv3 chega aos Arquivos do Azure NetApp como um UID numérico. Se um usuário nomeado user1 com uma ID numérica de tentar acessar a montagem NFSv3, a solicitação de 1001 autenticação chegará como ID 1001numérico . Em seguida, os Arquivos NetApp do Azure usam a ID 1001 numérica e tentam resolver 1001 para um nome de usuário. Esse nome de usuário é necessário para mapear para um usuário válido do Windows, porque as permissões NTFS no volume conterão nomes de usuário do Windows em vez de uma ID numérica. Os Arquivos NetApp do Azure usarão o servidor de serviço de nome (LDAP) configurado para procurar o nome de usuário. Se o nome de usuário não puder ser encontrado, a autenticação falhará e o acesso será negado. Esta operação é por design, a fim de evitar o acesso indesejado a arquivos e pastas.
Mapeamento de nomes com base no estilo de segurança
A direção na qual o mapeamento de nome ocorre nos Arquivos NetApp do Azure (Windows para UNIX ou UNIX para Windows) depende não apenas do protocolo que está sendo usado, mas também do estilo de segurança de um volume. Um cliente Windows sempre requer um mapeamento de nome do Windows para UNIX para permitir o acesso, mas nem sempre precisa de um nome de usuário UNIX correspondente. Se nenhum nome de usuário UNIX válido existir no servidor de serviço de nome configurado, os Arquivos NetApp do Azure fornecerão um usuário UNIX padrão de fallback com o UID numérico de 65534 para permitir a autenticação inicial para conexões SMB. Depois disso, as permissões de arquivo e pasta controlarão o acesso. Como 65534 geralmente corresponde ao usuário, o nfsnobody acesso é limitado na maioria dos casos. Por outro lado, um cliente NFS só precisa usar um mapeamento de nome de UNIX para Windows se o estilo de segurança NTFS estiver em uso. Não há nenhum usuário padrão do Windows nos Arquivos do Azure NetApp. Dessa forma, se um usuário válido do Windows que corresponda ao nome solicitante não for encontrado, o acesso será negado.
A tabela a seguir detalha as diferentes permutações de mapeamento de nome e como elas se comportam dependendo do protocolo em uso.
| Protocolo | Estilo de segurança | Direção do mapeamento de nome | Permissões aplicadas |
|---|---|---|---|
| PME | UNIX | Windows para UNIX | UNIX (mode-bits ou ACLs NFSv4.x) |
| PME | NTFS | Windows para UNIX | NTFS ACLs (com base no compartilhamento de acesso SID do Windows) |
| NFSv3 | UNIX | Nenhum | UNIX (mode-bits ou ACLs NFSv4.x*) |
| NFSv4.x | UNIX | ID numérico para nome de usuário UNIX | UNIX (mode-bits ou ACLs NFSv4.x) |
| NFS3/4.x | NTFS | UNIX para Windows | NTFS ACLs (com base no SID do usuário mapeado do Windows) |
Observação
As regras de mapeamento de nome no Azure NetApp Files atualmente podem ser controladas somente usando LDAP. Não há nenhuma opção para criar regras explícitas de mapeamento de nome dentro do serviço.
Serviços de nome com volumes de protocolo duplo
Independentemente do protocolo NAS usado, os volumes de protocolo duplo usam conceitos de mapeamento de nome para manipular permissões corretamente. Como tal, os serviços de nome desempenham um papel crítico na manutenção da funcionalidade em ambientes que usam SMB e NFS para acesso a volumes.
Os serviços de nome atuam como fontes de identidade para usuários e grupos que acessam volumes NAS. Essa operação inclui o Active Directory, que pode atuar como uma origem para usuários e grupos do Windows e UNIX usando serviços de domínio padrão e funcionalidade LDAP.
Os serviços de nome não são um requisito rígido, mas altamente recomendados para volumes de protocolo duplo do Azure NetApp Files. Não há nenhum conceito de criação de usuários e grupos locais personalizados dentro do serviço. Como tal, para ter autenticação adequada e informações precisas do usuário e do proprietário do grupo em todos os protocolos, o LDAP é uma necessidade. Se você tiver apenas alguns usuários e não precisar preencher informações precisas de identidade de usuário e grupo, considere usar a opção Permitir que usuários NFS locais com LDAP acessem uma funcionalidade de volume de protocolo duplo. Lembre-se de que habilitar essa funcionalidade desabilita a funcionalidade de grupo estendido.
Quando clientes, serviços de nomes e armazenamento residem em áreas diferentes
Em alguns casos, os clientes NAS podem viver em uma rede segmentada com várias interfaces que têm conexões isoladas com os serviços de armazenamento e nome.
Um exemplo é se seu armazenamento reside nos Arquivos NetApp do Azure, enquanto seus clientes NAS e serviços de domínio residem no local (como uma arquitetura hub-spoke no Azure). Nesses cenários, você precisaria fornecer acesso à rede para os clientes NAS e os serviços de nome.
A figura a seguir mostra um exemplo desse tipo de configuração.
