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

Os servidores de arquivos são uma realidade na 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 uma pasta compartilhada em um servidor de arquivos.

No meu trabalho atual, acabei herdando várias maneiras diferentes de fazer isso, variando de dezenas de grupos nas ACLs a 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 (ambiente amplo, 150 mil funcionários, 90 mil computadores clientes, centenas de servidores de arquivos).

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

Aqui está um exemplo mostrando o que quero dizer:

Existe um compartilhamento chamado "Resultados do Teste" em um servidor de arquivos chamado FILE01 e você tem pessoas que precisam de acesso somente leitura, acesso de leitura e gravação e controle total. 1 recurso protegido * 3 níveis de acesso = 3 grupos de segurança. Em nosso ambiente AD, nós os criamos como grupos universais, para que possamos adicionar usuários / grupos facilmente a partir de qualquer um dos domínios da 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 "principais" e as permissões são:

"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 interna e os administradores internos com acesso Controle Total também. Quaisquer alterações em quem realmente obtém acesso a esse compartilhamento agora podem ser tratadas usando associações de grupos, em vez de precisar tocar na ACL (adicionando grupos de "Funções" que representam funções comerciais específicas, como gerentes, técnicos, analistas de controle de qualidade, etc. ou apenas individuais usuários para acesso único).

Duas questões:

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

2) Como você está lidando com as permissões do servidor de arquivos e a estrutura do grupo em seu ambiente? Pontos de bônus para aqueles que também estão trabalhando em grandes ambientes.

Minha abordagem é não usar permissões de arquivo no nível do arquivo / diretório; use as permissões no nível de compartilhamento de arquivos e defina a unidade de dados do sistema de arquivos do servidor inteiro como Everyone Full Control (que se torna discutível).

Ao longo dos anos (mais de 10 anos), descobri que as permissões NTFS são mais complexas e levam a mais erros. Se as permissões estiverem incorretas ou a herança for quebrada, você expõe os dados e é difícil encontrá-los e vê-los. Além disso, você está exposto ao problema de mover / copiar ... os usuários que movem 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 no geral compartilhe arquivos usando o Comp Mgmt MMC. Não faça o máximo ... os usuários se matam com conhecimento parcial / melhores intenções.

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 ​​entre recursos. Por exemplo, o RH pode ter acesso RW aos arquivos, enquanto MANAGERS pode ter R. Você também pode configurar a Enumeração Baseada em Acesso. Dê uma olhada no seguinte webcast:

Webcast do TechNet: Série de administração do Windows Server 2003 (parte 4 de 12): Gerenciamento de grupo (nível 200)

A enumeração baseada em acesso pode facilitar a vida também:

Enumeração baseada em acesso

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

Sua abordagem é basicamente a maneira que eu abordaria.
As únicas coisas que eu acrescentaria são:

1) Eu acrescentaria ao seu esquema de "papéis" avaliando o que eles precisam nos servidores, não em apenas um servidor que você provavelmente encontrará outliers, mas minha teoria é que, quando você os encontrar, crie outro grupo. na minha experiência, onde há um outlier, existem muitos.

2) AVALIARIA ESTRANTAMENTE 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 que com o domínio local e global, apenas o grupo é replicado para os servidores de catálogo global. Portanto, se você fizer uma alteração em um grupo universal, ela inicia uma replicação, enquanto que com o global e o domínio local, não.

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 obter recursos. Você não precisa necessariamente usar o Universal Groups se estiver criando grupos de recursos específicos do servidor.

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

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

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

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

Outras coisas gerais que eu faria é ter uma convenção de nomenclatura para os grupos, de modo que o nome do grupo seja igual ao nome da pasta do grupo (com FC / RW / RO anexado, se desejado) e cole o UNC na pasta na descrição do grupo (para que seu script de logon possa lê-lo novamente 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).

A prática padrão que uso no servidor de arquivos Windows desde o Windows 2000 (apresentada na série Mastering Windows Server da Mark Minasi, portanto, procure mais informações) é usar grupos locais para o aninhamento do servidor de arquivos.

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 no KERMIT para acesso e conceda a eles 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 são grupos locais, você pode colocar quaisquer outros grupos ou usuários que desejar - grupos locais de domínio, grupos globais, grupos universais, contas de usuário de qualquer domínio da sua floresta. Agora, o gerenciamento de direitos é local nos grupos do servidor de arquivos, e não no sistema de arquivos ou no AD.

Isso adiciona uma camada adicional ao gerenciamento de grupos, mas tem o benefício de permitir (digamos) administradores locais do site gerenciar seus próprios servidores de arquivos sem precisar de mais nada além dos direitos de administrador desse servidor de arquivos. Se você possui um tipo federado de estrutura de filial, onde cada escritório faz suas próprias coisas com seus servidores, isso pode ser um benefício real. Talvez você não queira conceder direitos de administrador do AD a algumas dezenas de administradores de sites locais.

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

Se o seu ambiente é rigorosamente padronizado e todos os servidores de arquivos são idênticos e replicados, então esta é obviamente mais uma camada de grupos que você não precisa. Além disso, se você sabe que precisa de um grupo específico do AD para ter os mesmos direitos em um compartilhamento existente em cada servidor de arquivos, precisará de alguma automação para manter isso.

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

Estou olhando para uma migração do NetWare para o Windows Server 2008, e isso tem me refletido muito ultimamente. O Server 2008 (e até certo ponto o Server 2003R2) possui alguns recursos muito bons que realmente facilitam essa transição. O Server 2008 vem com a Enumeração Baseada em Acesso pronta para uso. Esse é um recurso muito bom que permite que os usuários vejam apenas os diretórios aos quais 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 a ABE, o usuário final veria apenas um. O mesmo vale para ações compartilhadas. 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 nos quais eles não podem acessar. Embora não seja um problema da ACL, ele é um pouco relacionado, então eu trago à tona.

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

Devido ao nosso legado do Netware, temos um grande número de grupos que são nomeados com base em quem está neles, com alguns por aí, nomeados pelo que eles dão acesso. Para diretórios com acesso regulado, também usamos a nomenclatura "RO" "Completo".

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

No meu último trabalho, conseguimos configurar permissões para que os funcionários de RH que se candidatassem não pudessem ver seus próprios dados de aplicativo no servidor. Foram necessários alguns filtros de direitos de herança para fazer isso, que é semelhante à marca "herança de bloco" no Windows. A parte complicada lá foi documentar tudo, mas funcionou .

O melhor cenário é incluir todos os usuários em apenas um grupo de segurança para a função de trabalho do usuário. A função é delegada quando necessário.

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

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

A desvantagem é que os 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 emaranhada.