Escolher grupos de segurança (SharePoint Foundation 2010)
Aplica-se a: SharePoint Foundation 2010
Tópico modificado em: 2016-11-30
Este artigo descreve os grupos de segurança e distribuição contidos no AD DS (Serviços de Domínio Active Directory®). Ele também fornece recomendações para o uso desses grupos com o objetivo de organizar os usuários dos seus sites do SharePoint.
Neste artigo:
Decidir se você deseja adicionar grupos de segurança
Definir que grupos de segurança usar para conceder acesso a sites
Decidir se você deseja permitir acesso a todos os usuários autenticados
Decidir se você deseja permitir acesso a usuários anônimos
Introdução
O gerenciamento de usuários de sites do SharePoint é mais simples quando você atribui níveis de permissão a grupos em vez de usuários específicos. No AD DS, os seguintes grupos são normalmente usados para organizar usuários:
Grupo de distribuição Um grupo usado somente para distribuição de email e que não é habilitado para segurança. Os grupos de distribuição não podem ser listados em DACLs (listas de controle de acesso discricionário), que são usadas para definir permissões em recursos e objetos.
Grupo de segurança Um grupo que pode ser listado em DACLs. Um grupo de segurança também pode ser usado como entidade de email.
Você pode usar grupos de segurança para controlar permissões para seu site adicionando grupos de segurança a grupos do Sharepoint e concedendo permissões aos grupos do Sharepoint. Não é possível adicionar diretamente grupos de distribuição a grupos do Sharepoint, mas você pode expandir um grupo de distribuição e adicionar os membros individuais a um grupo do SharePoint. Se você usar esse método, deverá manter manualmente o grupo do SharePoint sincronizado ao grupo de distribuição. Se você usar grupos de segurança, não precisará gerenciar os usuários individuais no aplicativo do SharePoint. Como você incluiu o próprio grupo de segurança em vez dos membros individuais desse grupo, o AD DS gerencia os usuários para você.
Observação
Para facilitar o gerenciamento de segurança, os itens a seguir não são recomendados no gerenciamento de grupos do Active Directory.
-
Atribuir níveis de permissão diretamente a grupos do Active Directory.
-
Adicionar grupos de segurança que contenham grupos de segurança, contatos ou listas de distribuição aninhados.
Decidir se você deseja adicionar grupos de segurança
A adição de grupos de segurança a grupos do SharePoint fornece gerenciamento centralizado de grupos e de segurança. O grupo de segurança é o único local em que você gerencia usuários individuais. Após adicionar o grupo de segurança a um grupo do SharePoint, você não precisa gerenciar membros do grupo de segurança nesse grupo do SharePoint. Se um usuário for removido do grupo de segurança, ele será automaticamente removido do grupo do SharePoint.
No entanto, o uso de grupos de segurança em sites do SharePoint não oferece visibilidade completa do que está acontecendo. Por exemplo, quando um grupo de segurança é adicionado a um grupo do SharePoint para um site específico, o site não aparece em Meus Sites dos usuários. A Lista de Informações do Usuário não mostra usuários individuais até que eles tenham contribuído para o site. Além disso, grupos de segurança com uma estrutura profundamente aninhada podem quebrar os sites do SharePoint.
Considerando as vantagens e desvantagens anteriores, estas são as recomendações:
Para sites de intranet que são amplamente acessados por seus usuários, use grupos de segurança, porque você não se importa com os usuários individuais que acessaram a home page da intranet local.
Para sites de colaboração que são acessados por um pequeno grupo de usuários, adicione usuários diretamente a grupos do SharePoint. Nesse caso, há uma necessidade maior de saber quem é membro, para que os membros do grupo conheçam os endereços de email uns dos outros e saibam como entrar em contato entre si.
Definir que grupos de segurança usar para conceder acesso a sites
Cada organização configura seus grupos de segurança de maneira diferente. Para facilitar o gerenciamento de permissões, os grupos de segurança devem ser:
Grandes e suficientemente estáveis para que você não precise adicionar grupos de segurança constantemente aos seus sites do SharePoint.
Pequenos o suficiente para que você possa atribuir as permissões corretas.
Por exemplo, um grupo de segurança chamado "todos os usuários do edifício 2" provavelmente não é pequeno o suficiente para atribuir permissões, a menos que todos os usuários do edifício 2 tenham o mesmo cargo, como auxiliares de contas a receber. Esse raramente é o caso e, portanto, você deve procurar um conjunto menor e mais específico de usuários, como "Contas a Receber".
Decidir se todos os usuários autenticados receberão permissão de acesso
Se quiser que todos os usuários do seu domínio possam ver o conteúdo do site, conceda acesso a todos os usuários autenticados (o grupo de segurança Usuários do Domínio do Windows). Esse grupo especial permite que todos os membros do domínio acessem um site (no nível de permissão de sua escolha), sem a necessidade de permitir acesso anônimo.
Decidir se deseja permitir acesso a usuários anônimos
Você pode habilitar o acesso anônimo para permitir que os usuários vejam páginas de forma anônima. A maioria dos sites da Internet permite a exibição anônima, mas pode pedir autenticação quando alguém deseja editar o site ou comprar um item em um site de compras. O acesso anônimo é desabilitado por padrão e deve ser concedido no nível do aplicativo Web no momento da sua criação.
Se o acesso anônimo estiver habilitado para o aplicativo Web, os administradores de sites poderão decidir se desejam conceder acesso anônimo a um site ou qualquer parte do conteúdo desse site.
O acesso anônimo baseia-se na conta de usuário anônima do servidor Web. Essa conta é criada e mantida pelo IIS (Serviços de Informações da Internet da Microsoft), não pelo site do SharePoint. Por padrão no IIS, a conta de usuário anônima é IUSR. Ao permitir o acesso anônimo, você está, de fato, concedendo a essa conta acesso ao site do SharePoint. A permissão de acesso a um site ou a listas e bibliotecas concede a permissão Exibir Itens à conta de usuário anônima. Contudo, mesmo com a permissão Exibir Itens, há restrições em relação ao que os usuários anônimos podem fazer. Usuários anônimos não podem:
Abrir sites para edição no Microsoft Office SharePoint Designer.
Exibir sites em Meus Locais de Rede.
Carregar ou editar documentos em bibliotecas de documentos, inclusive bibliotecas wiki.
Importante
Para melhorar a segurança de sites, listas ou bibliotecas, não habilite o acesso anônimo. A habilitação do acesso anônimo permite que os usuários contribuam em listas, discussões e pesquisas, o que possivelmente usará espaço em disco no servidor e outros recursos. O acesso anônimo também permite que os usuários anônimos descubram informações do site, inclusive endereços de email e qualquer conteúdo postado em listas, além de bibliotecas e discussões.
Políticas de permissão fornecem uma forma centralizada para configurar e gerenciar um conjunto de permissões que se aplica a apenas um subconjunto de usuários ou grupos em um aplicativo Web. Você pode gerenciar a política de permissão para usuários anônimos habilitando ou desabilitando o acesso anônimo para um aplicativo Web. Se você habilitar o acesso anônimo para um aplicativo Web, os administradores de site poderão então conceder ou negar acesso anônimo no nível de conjunto de sites, site ou item. Se o acesso anônimo for desabilitado para um aplicativo Web, nenhum site nele poderá ser acessado por usuários anônimos.
Nenhuma Nenhuma política. Esta é a definição padrão. Nenhuma restrição ou adição de outras permissões é aplicada a usuários anônimos do site.
Negar gravação Os usuários anônimos não podem gravar conteúdos, mesmo que o administrador do site tente especificamente conceder essa permissão à conta de usuário anônimo.
Negar Tudo Os usuários anônimos não têm qualquer tipo de acesso, mesmo que os administradores tentem especificamente conceder aos usuários anônimos acesso aos seus sites.
Para obter mais informações sobre políticas de permissão, consulte Manage permission policies for a Web application (SharePoint Foundation 2010).