Primeira demão de fundamentos de segurança do SharePoint / Evitar as armadilhas comuns

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:

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!

Technorati Tags:

8 pensamentos "Primeira demão de fundamentos de segurança do SharePoint / Evitar as armadilhas comuns

  1. Perry

    Armadilhas mais:

    * Existem certas permissões especiais disponíveis noutras partes do SSP e não é visível na seção de pessoas e grupos: "Permissões de serviços de personalização" e "Business Data Catalog"

    * Eu li que também existem permissões do SharePoint Designer especiais disponíveis em alguns xml arcano enterrado dentro html em algum lugar.

    * O primário e secundário os administradores para um conjunto de sites são mantidos noutro local em configurações de sites, e não é visível na seção de pessoas e grupos.

    * Certas contas têm mágico (especiais) habilidades, independentemente do que você vê na área de pessoas e grupos: Membros do grupo Administradores interno nos servidores web, e a conta de serviço do Farm.

    (PS: Excluir os comentários de spam poderia melhorar a legibilidade aqui.)

    Resposta
  2. Jean Wright
    Este é um post muito bom. Caí nessa armadilha em algumas ocasiões. Gerenciamento de segurança pode ter complexo quando você começar a misturar métodos de autenticação e segurança de diferente métodos de agrupamento. Isso precisa ser considerado como parte do processo de planejamento e não deve ser menosprezado..
    Resposta
  3. Mark Miller escreveu:
    (Nota do Paul: Mark me pediu para fazer uma pequena alteração ao seu comentário, mas eu não posso editar comentários de espaços ao vivo, então eu adicionei-a novamente aqui, com a mudança e eliminado o original).
    Paulo,
    A abordagem de resumo para apresentar esta informação se saiu muito bem. Eu gostei especialmente as armadilhas"" seção, desde que caí no alguns desses.
    Outra coisa que você disse que bateu em casa: aprendizagem na segunda-feira não necessariamente não significa que você vai se lembrar na sexta-feira. Fico feliz que alguém além de mim está usando seu blog como um "tickler" sistema para aquelas coisas essenciais que não são feitas em uma base regular.
    Bom trabalho.
    Cumprimentos,
    Mark
    EndUserSharePoint.com

    Novembro 27 9:04 AM
    (http://www.EndUserSharePoint.com)

    Resposta
  4. Paul Galvin
    Acho que é provavelmente uma boa idéia para remover esses grupos padrão, especialmente o contribuinte e o proprietário. Eles são atrase e facilmente confundido. Eu prefiro usar "todos os usuários autenticados" no lugar de um visitante"" grupo também. Se um determinado conjunto de usuários devem acessar apenas read-only então eu recomendaria a criação de um grupo de anúncios ou um grupo do SharePoint com um nome descritivo apropriadamente, EG. "Logística visitantes".
    –Paul G
    Resposta
  5. Sem nome
    Parece que a primeira coisa que você deve fazer é só despejar o visitante, Colaborador e dono de grupos e substituí-los com seus próprios grupos lógicos. Isso faria sentido fazer?
    Resposta

Deixar uma resposta

seu endereço de e-mail não será publicado. Campos obrigatórios são marcados *