Esta é uma abordagem recomendada / válida para permissões de servidor de arquivos?

Question

Servidores de arquivos são um fato da vida em TI e estou curioso para saber se existem práticas geralmente aceitas (hesito em usar a palavra "melhor" aqui) para criar grupos e aplicar permissões para gerenciar o acesso de clientes a um pasta compartilhada em um servidor de arquivos.

No meu trabalho atual, acabei herdando uma grande confusão de maneiras diferentes de fazer isso, desde dezenas de grupos nas ACLs até apenas colocar usuários individuais diretamente no sistema de arquivos. Minha tarefa era limpar a bagunça e criar algum tipo de maneira padronizada de abordar isso em toda a empresa (grande ambiente, 150 mil funcionários, 90 mil computadores clientes, centenas de servidores de arquivos).

Do meu entendimento do problema, parece que você precisa, no mínimo, de um grupo por nível de acesso obrigatório por recurso protegido. Esse modelo parece oferecer a maior flexibilidade, pois você não precisa mais tocar nas permissões do sistema de arquivos, a menos que seja necessário oferecer suporte a um nível de acesso diferente. A desvantagem é que você criará mais grupos do que reutilizando o mesmo grupo em vários recursos compartilhados.

Aqui está um exemplo mostrando o que quero dizer:

Existe um compartilhamento chamado "Test Results" em um servidor de arquivos chamado FILE01 e você tem pessoas que precisam de acesso somente leitura, acesso de leitura / gravação e controle total. 1 recurso protegido * 3 níveis de acesso = 3 grupos de segurança. Em nosso ambiente do AD, nós os criamos como grupos universais para que possamos adicionar usuários / grupos facilmente de qualquer um dos domínios na floresta. Como cada grupo se refere exclusivamente a uma pasta compartilhada e a um nível de acesso, os nomes dos grupos incorporam esses dados "chave" e as permissões são assim:

"FILE01-Test Results-FC"  --  Full Control
"FILE01-Test Results-RW"  --  Read & Write
"FILE01-Test Results-RO"  --  Read Only

Normalmente, também incluiríamos a conta SYSTEM integrada e os administradores integrados com acesso de Controle Total também. Quaisquer alterações em quem realmente obtiver o acesso a esse compartilhamento agora podem ser manipuladas usando associações de grupo em vez de precisar tocar na ACL (adicionando grupos de "Função" representando funções específicas de negócios como Gerentes, Técnicos, Analistas de controle de qualidade etc. usuários para acesso único).

Duas perguntas:

1) Esta é realmente uma abordagem recomendada ou válida para lidar com permissões ou estou perdendo alguma solução mais simples e elegante? Eu estaria especialmente interessado em quaisquer soluções que usem herança, mas ainda mantenham a flexibilidade em não precisar re-ACL em grandes partes dos sistemas de arquivos quando as coisas mudarem.

2) Como você está lidando com permissões de servidor de arquivos e estrutura de grupo em seu ambiente? Pontos de bônus para quem também trabalha em grandes ambientes.

    

Answer 1

Minha abordagem é não usar permissões de arquivo no nível de arquivo / diretório; use permissões de nível de compartilhamento de arquivos e defina toda a unidade de dados do sistema de arquivos do servidor para Todos Controle Total (que se torna discutível).

Ao longo dos anos (10+), descobri que as permissões de NTFS são mais complexas e levam a mais erros. Se as permissões estiverem erradas ou a herança for quebrada, você exporá os dados e será difícil encontrá-los e vê-los. Além disso, você está exposto ao problema de mover / copiar ... os usuários que estão movendo arquivos também movem a ACL do arquivo, enquanto a cópia herda a ACL de destino.

Use seus grupos de leitura / gravação da mesma forma, mas em todo o compartilhamento de arquivos usando o Comp Mgmt MMC. Não faça o máximo ... os usuários se atirarão com conhecimentos parciais / melhores intenções.

    

Answer 2

Essa abordagem não é ruim. Como regra, nunca use usuários individuais para adicionar permissões - use um grupo. Grupos podem, no entanto, ser usados em vários recursos. Por exemplo, HR pode ter acesso RW a arquivos enquanto MANAGERS pode ter R. Você também pode configurar a Enumeração Baseada no Acesso. Dê uma olhada no seguinte webcast:

Webcast do TechNet: Administração do Windows Server 2003 Série (Parte 4 de 12): Gerenciamento de Grupo (Nível 200)

A enumeração baseada no acesso pode facilitar ainda mais a vida:

Enumeração baseada em acesso

A ABE pode ajudar a reduzir o número de ações diferentes que você precisa administrar.

    

Answer 3

Sua abordagem é basicamente a maneira como eu abordaria isso.
As únicas coisas que gostaria de acrescentar são estas:

1) Eu adicionaria ao seu esquema de "papéis", avaliando o que eles precisam através de servidores, não apenas em um servidor, você provavelmente se deparará com valores atípicos, mas minha teoria com eles é quando você os depara com eles, cria outro grupo. na minha experiência, onde há um outlier, há muitos.

2) Gostaria de reavaliar a necessidade de grupos universais para tudo, à medida que você recebe uma replicação com eles, pois os membros e grupos dentro do grupo Universal são replicados para os servidores do Catálogo Global, enquanto apenas com o domínio local e global o grupo é replicado para os servidores de catálogo global. Então, se você fizer uma mudança em um grupo universal, ele inicia uma replicação, enquanto que com o global e o domínio local, isso não acontece.

    

Answer 4

Seu método de usar o grupo de recursos para cada nível de acesso está correto. A única coisa que eu consideraria é usar grupos locais de domínio para recursos. Você não precisa necessariamente usar os Grupos universais se estiver criando grupos de recursos específicos do servidor.

A desvantagem de usar os Grupos Locais de Domínio para recursos é que você acaba com mais grupos totais. A vantagem é que você tem menos problemas com replicação, como observou Zypher.

    

Answer 5

A abordagem proposta parece bastante sólida. Uma coisa a observar é a maneira como você inicialmente configurou os compartilhamentos de arquivos. A prática recomendada é ter um único compartilhamento de nível superior, contendo subpastas para as quais você atribui as permissões do grupo. O NTFS pode então ignorar o "Atravessar pasta / executar arquivo" na pasta de nível superior e conceder acesso à subpasta.

A estrutura seria semelhante a \ servername \ sharename \ group-folder, com permissões de compartilhamento precisando ser definidas apenas na pasta "sharename", e as permissões NTFS definidas na pasta "group-folder".

Seu servidor de arquivos também poderá funcionar melhor com esse tipo de configuração.

Outras coisas que gostaria de fazer é ter uma convenção de nomenclatura para os grupos, de modo que o nome do grupo seja o mesmo que o nome da pasta do grupo (com FC / RW / RO anexado, se desejado) e colocar o UNC na pasta. a descrição do grupo (para que seu script de logon possa lê-lo de volta e definir um mapeamento de unidade dessa maneira e também para que você possa ver com mais facilidade quais pastas compartilhadas se aplicam a quais grupos).

    

Answer 6

A prática padrão que tenho usado para o servidor de arquivos do Windows desde o Windows 2000 (mostrada na série Mastering Windows Server da Mark Minasi, procure outras informações) é usar grupos que são locais para o próprio servidor de arquivos para aninhamento .

Por exemplo, considere um servidor de arquivos chamado KERMIT em um domínio chamado MUPPETS.

Digamos que o KERMIT tenha alguns compartilhamentos de arquivos:

\KERMIT\Applications
\KERMIT\Finance
\KERMIT\Sales
\KERMIT\Manufacturing

Crie grupos locais para o KERMIT para acesso e conceda-lhes permissões no sistema de arquivos exatamente como você especificou (por exemplo, um grupo por nível de acesso por compartilhamento)

KERMIT\Applications-RO
KERMIT\Applications-RW
KERMIT\Applications-FC
KERMIT\Finance-RO
[...]

Como esses grupos são locais, você pode colocar quaisquer outros grupos ou usuários que desejar neles - grupos locais de domínio, grupos globais, grupos universais, contas de usuário de qualquer domínio em sua floresta. O gerenciamento de direitos agora é local para os grupos do servidor de arquivos, e não para o sistema de arquivos ou o AD.

Isso adiciona uma camada adicional ao gerenciamento de grupos, mas tem o benefício de permitir (digamos) que os administradores locais gerenciem seus próprios servidores de arquivos sem precisar de nada além de direitos de administrador para esse servidor de arquivos. Se você tem um tipo federado de estrutura de filial, onde cada tipo de escritório faz sua própria coisa com seus servidores, isso pode ser um benefício real. Talvez você não queira conceder direitos de administrador do AD a algumas dúzias de administradores de sites locais.

Ele também evita que seu AD fique cheio de muitos grupos (um grupo por nível de acesso por compartilhamento por servidor pode aumentar muito rapidamente) e minimiza a replicação de grupo entre os GCs. Ele permite que você reserve seus grupos de anúncios para funções em vez de permissões.

Se o seu ambiente for rigorosamente padronizado e todos os servidores de arquivos forem idênticos e replicados, isso obviamente será mais uma camada de grupos desnecessários. Além disso, se você sabe que precisa de um determinado grupo do AD para ter os mesmos direitos em um compartilhamento que existe em cada servidor de arquivos, precisará de alguma automação para manter isso.

Em poucas palavras, quanto mais diferentes forem os seus servidores de arquivos, mais os grupos locais de máquinas farão sentido. Quanto mais eles forem semelhantes, mais você deseja usar o sistema que está usando no momento.

    

Answer 7

Eu estou olhando para uma migração do NetWare para o Windows Server 2008, então isso está muito na minha cabeça ultimamente. O Server 2008 (e até certo ponto o Server 2003R2) tem alguns recursos muito interessantes que realmente facilitam essa transição. O Server 2008 vem com a Enumeração Baseada em Acesso fora da caixa. Este é um recurso muito interessante que permite aos usuários ver apenas os diretórios nos quais eles têm direitos. Se você tem um compartilhamento como ...

\\ user-home-srv \ homes \

Sem o ABE, o usuário final veria dezenas / centenas / milhares de diretórios. Com o ABE, o usuário final veria apenas um. O mesmo vale para compartilhamentos compartilhados. Com a ABE, você pode ter um único volume enorme para todos os diretórios departamentais, se desejar, e não enviar spam para os usuários com diretórios em que eles não possam entrar. Apesar de não ser um problema da ACL, ele é um pouco relacionado, então eu o apresento.

Outra coisa que o Server 2008 parece fazer melhor do que suas versões anteriores é a herança ACL. Parece mais rápido propagar para a folha uma alteração na ACL no topo de uma grande árvore.

Devido ao nosso legado Netware, temos um grande número de grupos que são nomeados com base em quem está neles, com alguns nomeados para o que dão acesso. Para diretórios que possuem acesso regimentado, também usamos a nomenclatura "RO" "Full".

Temos um volume "compartilhado" monolítico (ainda no NetWare, mas planejamos tê-lo monolítico quando mudamos para o Windows), que é o volume compartilhado único para todos os 4.400 trabalhadores e tem mais de 3,5 milhões de arquivos nele. Os diretórios de nível superior são todos nomes de departamento e cada departamento regula o que acontece dentro deles. Existem algumas exceções para os departamentos realmente grandes, aqueles que possuem um segundo nível de diretórios com ACLs.

No meu último trabalho, conseguimos configurar as permissões para que os funcionários de RH que se candidatassem a empregos não pudessem ver os dados de seus próprios aplicativos em seus servidores. Foram necessários alguns filtros inheritance-rights para isso, o que é semelhante à tag "herança de bloco" no Windows. A parte complicada era documentar tudo, mas funcionou .

    

Answer 8

O melhor cenário possível é que cada usuário seja adicionado a apenas um grupo de segurança para a função de trabalho do usuário. A função, então, é o acesso delegado, quando necessário.

Da mesma forma, uma pasta compartilhada deve receber acesso usando grupos de segurança "resource", como o exemplo "FILE01-Test Results-RW". Isso conterá as funções, funções de departamento ou outros grupos aplicáveis.

O lado positivo desse design é que você delega acesso por grupo (equipe, departamento, etc.) e não acesso único que pode ser difícil de acompanhar. Quando um usuário transfere para outro departamento, você precisa limpar todo o acesso antigo.

A desvantagem é que grupos podem ser mal utilizados. Faça distinções claras sobre o uso dos grupos, para que os grupos de recursos atribuídos a um compartilhamento não sejam reutilizados como se fossem grupos departamentais, criando uma confusão de acesso.