Lista de verificação de auditoria de ACL do NAS doméstico para acesso SMB, NFS e contentores

A abordagem segura consiste em tratar uma auditoria de ACL orientada pelas evidências, que mapeia identidades, permissões efetivas e herança em todos os caminhos de acesso, como uma sequência de etapas observáveis, e não como um único comando.

Num NAS doméstico que exporta dados partilhados para SMB, NFS e contentores, o risco prático é o mesmo caminho do NAS conceder acessos efetivos diferentes através de SMB, NFS e montagens bind de contentores. Registe a identidade atual e o ponto de recuperação, comece pelo diferenciador menos invasivo, interprete os resultados de aprovação e reprovação antes de alterar outra variável e pare quando o armazenamento ficar instável ou quando a única cópia recuperável ficar exposta. O fluxo de trabalho abaixo só termina quando a carga de trabalho original for bem-sucedida ou quando as evidências atingirem um limite de escalamento.

Congele o estado das permissões e mapeie todas as identidades

Escolha uma partilha representativa e registe o respetivo conjunto de dados ou sistema de ficheiros, nomes das exportações, definição da partilha SMB, exportação NFS, montagens bind dos contentores e propriedade atual. Capture os valores numéricos de UID e GID no NAS e dentro de cada contentor; nomes de utilizador correspondentes não provam que as identidades subjacentes sejam iguais.

As ACL POSIX acrescentam utilizadores nomeados, grupos nomeados, entradas predefinidas e uma máscara que pode limitar os respetivos direitos efetivos. O comportamento da máscara de ACL POSIX explica por que razão a máscara apresentada por getfacl pode fazer com que uma entrada aparentemente permissiva se comporte de forma mais restrita, o que é essencial ao comparar uma vista da linha de comandos com o comportamento de SMB ou NFS.

Não execute chmod, chown ou substituições recursivas de ACL durante o inventário. Guarde primeiro o resultado de getfacl -p e a configuração dos serviços; a linha de base é aprovada quando cada identidade de cliente pode ser associada a uma identidade numérica no servidor ou explicitamente marcada como não mapeada.

Teste o acesso efetivo através de cada protocolo

Crie um utilizador dedicado à auditoria e um diretório descartável dentro da partilha. A partir do Windows ou macOS através de SMB, de um cliente Linux NFS e do contentor de destino, teste separadamente a listagem, leitura, criação, mudança de nome e eliminação. Registe o proprietário, grupo, modo, ACL e protocolo utilizado após cada operação.

Mantenha distintas a autenticação e a autorização do sistema de ficheiros. Um início de sessão SMB pode ser bem-sucedido enquanto a identidade Unix mapeada não tem permissão de escrita; um cliente NFS pode apresentar um ID numérico que o servidor aceita, mas que corresponde ao proprietário local errado. Altere apenas uma variável de identidade ou ACL entre testes.

Um caminho só é aprovado quando os direitos observados correspondem à matriz de acesso pretendida e os ficheiros recém-criados recebem o proprietário, grupo e ACL predefinida esperados. Se um protocolo se comportar de forma diferente, interrompa as alterações abrangentes e rastreie a camada de mapeamento desse protocolo antes de tocar no sistema de ficheiros partilhado.

Inspecione a herança, as máscaras e os mapeamentos dos contentores

Compare a ACL predefinida do diretório principal com a ACL de acesso de ficheiros e diretórios recém-criados. Verifique a máscara da ACL após alterações de grupo, confirme se o serviço SMB aplica máscaras de criação ou de diretório e identifique as aplicações que substituem ficheiros atomicamente, pois a substituição pode produzir uma herança diferente da edição no local.

Nos contentores, inspecione o utilizador de execução, os grupos suplementares, o remapeamento do espaço de nomes de utilizadores e o caminho do anfitrião montado por bind. O guia relacionado da ZimaSpace sobre acesso a bases de dados num volume Docker montado através da rede é útil quando o mapeamento de nomes NFSv4 é a camada com falhas; esta auditoria continua focada em provar os direitos de ponta a ponta nos três caminhos.

Não resolva um problema de mapeamento executando a aplicação como root. Se o contentor não conseguir criar o ficheiro descartável, alinhe o UID, GID ou grupo suplementar suportado com a política do NAS e repita o mesmo teste antes de alterar qualquer árvore de produção.

Featured

ZimaCube 2 NAS Pessoal Cloud para Casa

ZimaCube2

$799.00 - $2,499.00

Buy Now

Aplique a correção mais restrita e preserve as evidências

Corrija uma camada de cada vez: primeiro o mapeamento de identidades, depois a pertença a grupos, em terceiro lugar as predefinições herdadas e, por último, as ACL de ficheiros excecionais. Aplique as alterações ao diretório descartável, verifique novamente todas as operações e só depois prepare uma alteração delimitada para a subárvore de produção, com uma ACL de reversão guardada.

Após a implementação, reinicie ou volte a ligar os clientes que armazenam credenciais em cache, volte a montar o NFS quando necessário e reinicie apenas os contentores cuja lista de grupos é fixada no arranque do processo. Repita a mesma matriz de testes e verifique que tanto os ficheiros existentes como os novos se comportam conforme previsto.

A auditoria termina quando todas as ações permitidas e negadas correspondem à matriz documentada, os novos objetos herdam corretamente e a ACL guardada consegue restaurar o estado anterior. Escale o problema em vez de executar alterações recursivas às cegas quando a propriedade é intencionalmente mista, os instantâneos ou ligações físicas complicam a reversão ou o armazenamento do NAS comunica erros.