ATUALIZAÇÃO 12/18/07: Consulte o artigo de Paul Liebrand para algumas consequências técnicas de remover ou modificar os nomes de grupo padrão (Consulte também o seu comentário abaixo).

Visão geral:

Segurança do SharePoint é fácil de configurar e gerenciar. No entanto, Ele provou para ser difícil para alguns administradores pela primeira vez para realmente envolver suas mãos em torno dela. Não só isso, Eu vi alguns administradores chegar a um entendimento perfeito na segunda-feira só para tê-la perdido até sexta-feira porque não tinham que fazer alguma configuração no tempo intermediárias. (Eu admito que tem este problema me). Esta entrada de blog espero que fornece uma útil cartilha de segurança do SharePoint e aponta para algumas práticas recomendadas de configuração de segurança.

Nota importante:

Esta descrição baseia-se fora da caixa de segurança do SharePoint. Minha experiência pessoal é orientada em torno de MOSS, então pode haver algumas coisas específicas do MOSS, Mas creio que é preciso para WSS. Espero que ninguém ver quaisquer erros ou omissões indic que nos comentários ou correio eletrónico a mim. Eu vou fazer correções post pressa.

Fundamentos:

Para efeitos desta visão geral, há quatro aspectos fundamentais para a segurança: usuários/grupos, objetos de segurança, herança e níveis de permissão.

Usuários e grupos quebrar para baixo para:

• Usuários individuais: Puxado de active directory ou criado diretamente no SharePoint.
• Grupos: Mapeada diretamente do active directory ou criado no SharePoint. Grupos são uma coleção de usuários. Grupos são globais em um conjunto de sites. Eles nunca "atados" a um objeto específico.

Objetos de segurança quebrar para baixo pelo menos:

• Sites
• Bibliotecas de documentos
• Itens individuais em listas e bibliotecas de documentos
• Pastas
• Várias configurações de BDC.

Há outros objetos protegíveis, mas você começa a foto.

Níveis de permissão: Um pacote de granulado / direitos de acesso de baixo nível que incluem coisas como criar/ler/apagar entradas nas listas.

Herança: Por padrão entidades herdam as configurações de segurança de seu objeto contendo. Subsites herdam a permissão de seu pai. Bibliotecas de documentos herdam de seu site. Assim por diante e assim por diante.

Usuários e grupos se relacionam a objetos protegidos através de níveis de permissão e herança.

As regras de segurança mais importantes para compreender, Ever 🙂 :

1. Grupos são simplesmente a coleções de usuários.
2. Grupos são globais dentro de um conjunto de sites (ou seja. não há nenhuma coisa como um grupo definido a nível local).
3. Nome do grupo não obstante, grupos não, em e de si, ter qualquer nível específico de segurança.
4. Grupos têm segurança no contexto de um objeto protegível específico.
5. Você pode atribuir diferentes níveis de permissão para o mesmo grupo para cada objeto de segurança.
6. Diretivas de aplicativo Web superam tudo isso (Veja abaixo).

Os administradores de segurança perdidos em um mar de Listagens de grupo e usuário podem sempre contar com estes axiomas para gerenciar e entender a sua configuração de segurança.

Armadilhas comuns:

• Nomes de grupo implicam falsamente a permissão: Fora da caixa, SharePoint define um conjunto de grupos cujos nomes implicam um nível inerente de segurança. Considerar o grupo "Colaborador". Um desconhecido com segurança SharePoint pode bem Olha esse nome e assumir que qualquer membro desse grupo pode "contribuir" para qualquer site/lista/biblioteca no portal. Isso pode ser verdade, mas não porque o nome do grupo é "colaborador". Isto só é verdade fora da caixa, porque o grupo proporcionou um nível de permissão que permite que eles para adicionar/editar/excluir conteúdo no site da raiz. Por meio de herança, os colaboradores"" grupo também pode adicionar/editar/excluir conteúdo em cada subsite. "Infiltrações" a cadeia de herança e alterar o nível de permissão de um subsite tal que os membros do chamado "contribuinte" Grupo não pode contribuir em todos os, mas apenas ler (por exemplo). Isso não seria uma boa idéia, Obviamente, uma vez que seria muito confuso.
• Grupos não são definidos no nível de um site. É fácil de ser confundido com a interface do usuário. A Microsoft fornece um link conveniente para gerenciamento de usuário/grupo através "pessoas e grupos do site, todas as" link. É fácil acreditar que quando eu estou no site "xyzzy" e criar um grupo através pessoas do xyzzy e grupos link que acabou de criar um grupo que só existe no xyzzy. Isso não é o caso. Na verdade, eu criei um grupo para a coleção de todo o site.
• Associação de grupos não variam por local (ou seja. é o mesmo em todos os lugares que o grupo é usado): Considere o grupo "proprietário" e dois sites, "HR" e "Logística". Seria normal pensar que dois indivíduos separados possuiria esses sites — um proprietário de HR e uma logística. A interface do usuário torna mais fácil para um administrador de segurança danificar este cenário. Se não te conhecesse, Pode acessar os links de pessoas e grupos através do site do HR, Selecione os proprietários"" Grupo e adicionar meu dono HR ao grupo. Um mês depois, Logística vem na linha. Ter acesso a pessoas e grupos a partir do site da logística, Adicionar a puxar para cima os proprietários"" Grupo. Eu vejo o proprietário HR lá e removê-la, pensando que estou tirando ela de proprietários na área de logística. Na verdade, Estou tirando ela do grupo global de proprietários. Hilaridade segue.
• Na falta de nome grupos com base em funções específicas: Os aprovadores"" o grupo é um exemplo perfeito. O que pode a membros de aprovar este grupo? Onde eles possam aprová-lo? Eu realmente quero departamento de logística de pessoas para ser capaz de aprovar documentos RH? Claro que não. Sempre grupos de nome com base em seu papel dentro da organização. Isso reduzirá o risco de que o grupo é atribuído um nível de permissão inadequado para um determinado objeto protegível. Grupos de nome com base na sua função pretendida. No cenário anterior HR/logística, Eu deveria ter criado dois novos grupos de: "Proprietários de HR" "proprietários de logística e" e atribuir níveis de permissão sensata para cada um e a quantidade mínima necessária para os usuários a fazer o seu trabalho.

Outras referências úteis:

• Do Web aplicativo diretiva pegadinha: http://paulgalvin.spaces.live.com/blog/cns!1CC1EDB3DAA9B8AA!255.entry
• Câmara de compensação para a segurança do SharePoint: http://www.sharepointsecurity.com/
• Links do Joel Oleson: http://blogs.msdn.com/joelo/archive/2007/08/23/sharepoint-security-and-compliance-resources.aspx

Se você fez isso agora:

Por favor, deixe-me saber a sua opinião através dos comentários ou me enviar e-mail. Se você sabe outras boas referências, por favor, faça o mesmo!