Compreender o estilo de segurança de protocolo duplo e os comportamentos de permissão nos Arquivos NetApp do Azure
SMB e NFS usam modelos de permissão diferentes para acesso de usuários e grupos. Como resultado, um volume de Arquivo NetApp do Azure 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 forem necessários NFS e SMB nos mesmos conjuntos de dados (protocolo duplo), 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.
Nota
Os estilos de segurança são escolhidos na criação do volume. Uma vez escolhido o estilo de segurança, este 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 detalhadas de segurança/auditoria.
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 através de SMBs que mapeiam para atributos UNIX (somente leitura/gravação/execução; sem permissões especiais). - As ACLs NFSv4.x não têm gerenciamento de GUI. O gerenciamento é feito somente via CLI usando nfs4_getfacl e nfs4_setfacl comandos. - Se um arquivo ou pasta tiver ACLs NFSv4.x, a guia de propriedades de segurança do Windows não poderá exibi-las. |
| NTFS | - Os clientes UNIX não podem definir atributos através de 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 possa ser traduzida 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 peça 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 PME | Necessidade de segurança granular |
|---|---|---|---|
| UNIX | X | - | X (usando ACLs NFSv4.x) |
| NTFS | - | X | X |
Como funciona o mapeamento de nomes nos Arquivos NetApp do Azure
Nos Arquivos NetApp do Azure, 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 de Arquivos NetApp do Azure, 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 Ative 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 Ative Directory.
- As associações de grupo também são consultadas e tudo é adicionado a um cache de credenciais para um 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 Ative Directory podem ser usados com protocolos duplos.
- Atualmente, os únicos usuários locais que podem ser usados com volumes de protocolo duplo sã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 a autenticação de volume de protocolo duplo é o mapeamento de nomes de usuário para interoperabilidade entre UNIX e Windows.
O estilo de segurança de um volume determina como um mapeamento de nome ocorre nos Arquivos NetApp do Azure. As semânticas de permissão do Windows e UNIX são diferentes. 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 NetApp do Azure 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 nomes (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 Windows para UNIX para permitir o acesso, mas nem sempre precisa de um nome de usuário UNIX correspondente. Se não existir nenhum nome de usuário UNIX válido no servidor de serviço de nomes configurado, os Arquivos NetApp do Azure fornecerão um usuário UNIX padrão de fallback com o UID numérico de para permitir a autenticação inicial para 65534 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 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 NetApp do Azure. Como tal, se não for possível encontrar um utilizador válido do Windows que corresponda ao nome requerente, 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 nomes | Permissões aplicadas |
|---|---|---|---|
| SMB | UNIX | Windows para UNIX | UNIX (bits de modo ou ACLs NFSv4.x) |
| SMB | NTFS | Windows para UNIX | NTFS ACLs (com base no compartilhamento de acesso ao SID do Windows) |
| NFSv3 | UNIX | None | UNIX (bits de modo ou ACLs NFSv4.x*) |
| NFSv4.x | UNIX | ID numérico para nome de usuário UNIX | UNIX (bits de modo ou ACLs NFSv4.x) |
| NFS3/4.x | NTFS | UNIX para Windows | NTFS ACLs (com base no SID do usuário do Windows mapeado) |
Nota
Atualmente, as regras de mapeamento de nome nos Arquivos NetApp do Azure podem ser controladas somente usando LDAP. Não há 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 lidar com permissões corretamente. Como tal, os serviços de nomes 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 nomes atuam como fontes de identidade para usuários e grupos que acessam volumes NAS. Essa operação inclui o Ative Directory, que pode atuar como uma fonte para usuários e grupos 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 de usuários e proprietários de grupos 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 os clientes, os serviços de nome e o 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 o seu armazenamento reside nos Arquivos NetApp do Azure, enquanto seus clientes NAS e serviços de domínio residem todos 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.
