Planejar a segurança do site (Office SharePoint Server)

Atualizado em: 2009-06-25

Neste artigo:

• Sobre os elementos de segurança de sites

• Sobre a atribuição de permissões

• Sobre permissões refinadas e herança de permissão

• Escolher os níveis de segurança de site a serem usados

• Planejamento de herança de permissão

• Office Word

• Planilha

Este artigo descreve o planejamento de controle do acesso e autorização no conjunto de sites e níveis de subsite, sem abordar o planejamento de segurança de servidor ou farm de servidores. Para obter informações sobre outros aspectos de segurança, como métodos de autenticação e criptografia, consulte Planejar a segurança de site e de conteúdo (Office SharePoint Server).

A segurança do site é controlada pela atribuição de permissões a usuários e grupos para um objeto protegível específico (como sites, listas ou itens). Para o planejamento de segurança do site, é preciso decidir:

• A que nível você deseja controlar as permissões de objetos protegíveis individuais. Por exemplo, você deseja controlar o acesso do site todo ou precisa especificar as configurações de segurança de uma lista, pasta ou item em particular?

• Como você deseja categorizar e gerenciar os usuários (usando grupos). Este artigo aborda os itens essenciais de segurança de um site, auxiliando-o na determinação de objetos protegíveis que precisam de permissões específicas. Para obter mais informações sobre a categorização de usuários em grupos, consulte Escolher quais grupos de segurança serão usados (Office SharePoint Server).

  Dica

  O modo como os grupos e permissões interagem foi bastante alterado desde as versões anteriores. Na versão anterior, os grupos no nível do site continham os usuários e as permissões, ou seja, quando um usuário era adicionado a um grupo de site, as permissões do usuário no site eram determinadas automaticamente. Nesta versão, os conceitos de grupos de usuários e permissões foram separadas. Os grupos do SharePoint no nível do conjunto de sites contêm os usuários, os níveis de permissão contêm as permissões e os grupos não têm nenhuma permissão até que sejam atribuídos a um nível de permissão para um objeto protegível específico (como um site, lista ou biblioteca, pasta, item ou documento).

Sobre os elementos de segurança de sites

Independentemente do tipo de site que você está criando, a segurança do site inclui estes cinco elementos:

• Permissões individuais de usuário   Permissões individuais que concedem a capacidade de executar ações específicas. Por exemplo, a permissão Exibir Itens concede ao usuário a capacidade de exibir itens em uma lista. Os administradores de farm podem controlar quais permissões estão disponíveis para o farm de servidores, usando a página Permissões do Usuário para Aplicativo Web na Administração Central (para abrir essa página, na página Gerenciamento de Aplicativos, em Segurança do Aplicativo, clique em Permissões do usuário para aplicativo Web.) Para obter informações sobre as permissões disponíveis, consulte User permissions and permission levels.

• Nível de permissão   Um conjunto predefinido de permissões que concede permissão a usuários para executar ações relacionadas. Os níveis de permissão padrão são: Acesso Limitado, Leitura, Colaboração, Design e Controle Total. Por exemplo, o nível de permissão Leitura inclui as permissões Exibir Itens, Abrir Itens, Exibir Páginas e Exibir Versões, entre outras, todas as quais são necessárias para ler documentos, itens e páginas de um site do SharePoint. As permissões podem ser incluídas em vários níveis de permissão. Os níveis de permissão podem ser personalizados por qualquer pessoa que tenha um nível de permissão que inclua a permissão Gerenciar Permissões. Para obter informações sobre os níveis de permissão padrão e quais permissões estão incluídas neles, consulte User permissions and permission levels.

• Usuário   uma pessoa que tem uma conta de usuário que pode ser autenticada por meio do método de autenticação utilizado para o servidor. Você pode adicionar usuários individuais e atribuir diretamente um nível de permissão para cada usuário. Os usuários não precisam fazer parte de um grupo. Recomenda-se atribuir permissões de forma geral para grupos em vez de usuários. Como é ineficiente manter as contas de usuários diretamente, você deve atribuir permissões com base no usuário somente como uma exceção. Para obter mais informações sobre tipos de contas de usuário, consulte User permissions and permission levels.

• Grupo   Um grupo de usuários. Pode ser um grupo de segurança do Windows (como Departamento_A) que você adiciona ao site ou um grupo do SharePoint, como Proprietários do Site, Membros do Site ou Visitantes do Site. Cada grupo do SharePoint recebe um nível de permissão padrão, mas o nível de permissão de qualquer grupo pode ser alterado conforme necessário. Qualquer pessoa que tenha um nível de permissão que inclua a permissão Criar Grupos (incluída no nível de permissão Controle Total, por padrão) pode criar grupos personalizados do SharePoint..

• Objeto protegível   Usuários ou grupos que recebem um nível de permissão para um objeto protegível específico: site, lista, biblioteca, pasta, documento ou item. Por padrão, as permissões para uma lista, biblioteca, pasta, documento ou item são herdados do site pai, ou da lista ou biblioteca pai. Entretanto, todos que tenham um nível de permissão para um objeto protegível específico que inclua a permissão Gerenciar Permissões pode alterar as permissões desse objeto protegível. Por padrão, as permissões são inicialmente controladas no nível do site, com todas as listas e bibliotecas herdando as permissões do site. Use as permissões no nível da lista, pasta e item para controlar adicionalmente quais usuários podem exibir ou interagir com o conteúdo do site. Você pode voltar a herdar permissões de uma lista pai, do site como um todo ou de um site pai, a qualquer momento.

Sobre a atribuição de permissões

Você pode atribuir um nível de permissão a um usuário ou grupo para um objeto protegível específico (site, lista ou item). Usuários individuais ou grupos podem ter níveis de permissão diferentes para objetos protegíveis diferentes.

O diagrama a seguir ilustra como os usuários e grupos recebem níveis de permissões específicos para um determinado objeto protegível.

Sobre permissões refinadas e herança de permissão

Você pode usar permissões refinadas (permissões no nível de uma lista ou biblioteca, de uma pasta ou de um item ou documento) para controlar com mais exatidão quais ações os usuários podem efetuar em seu site. Os seguintes objetos protegíveis estão disponíveis para atribuições de permissão:

• Site   Controla o acesso ao site como um todo.

• Lista ou biblioteca   Controla o acesso a uma lista ou biblioteca específica.

• Pasta   Controla o acesso às propriedades de uma pasta (como o nome da pasta).

• Item ou documento   Controla o acesso a um item ou documento de uma lista específica.

Herança de permissão e permissões refinadas

Por padrão, as permissões em um site são herdadas do site. Entretanto, você pode interromper essa herança para qualquer objeto protegível que esteja em um nível inferior na hierarquia por meio da edição das permissões (criando uma atribuição de permissão exclusiva) desse objeto protegível. Por exemplo, você pode editar as permissões de uma biblioteca de documentos que interrompa a herança do site. Entretanto, a herança é interrompida apenas para o objeto protegível específico e qualquer coisa dentro do objeto que herde dele; o restante das permissões do site são inalteradas. Você pode tornar um objeto protegível mais ou menos acessível que o site pai. Você pode voltar a herdar as permissões da lista ou do site pai a qualquer momento..

Herança de permissão e subsites

Os próprios sites são objetos protegíveis para os quais as permissões podem ser atribuídas. Você pode configurar que os subsites herdem permissões de um site pai ou pode criar permissões exclusivas para um site específico. A herança de permissões é a forma mais fácil de gerenciar um grupo de sites. No entanto, se um subsite herdar permissões de seu pai, o conjunto de permissões é compartilhado. Isso significar que os proprietários dos subsites que herdarem as permissões do site pai podem editar as permissões do pai. Se você deseja alterar as permissões de apenas um subsite, interrompa as permissões de herança e faça a alteração.

Os subsites podem herdar permissões de um site pai. Você pode interromper a herança de permissões de um subsite criando permissões exclusivas. Esse processo copia os grupos, usuários e níveis de permissão de um site pai e, em seguida, interrompe a herança. Se você fizer a alteração de permissões exclusivas para herdadas, os usuários, grupos e níveis de permissão começarão a ser herdados, e você perderá todos os usuários, grupos e níveis de permissão que eram definidos exclusivamente no subsite. Os níveis de permissão também podem ser herdados (e são, como padrão), tanto que o nível de permissão de Leitura é o mesmo, não importa a que objeto é atribuído. Você pode interromper a herança editando o nível de permissão. Por exemplo, se não quiser que o nível de permissão de Leitura em um determinado subsite inclua a permissão para Criar Alertas).

Escolher os níveis de segurança de site a serem usados

Quando você cria sua estrutura de permissões, é importante encontrar o equilíbrio entre a facilidade de administração, o desempenho e a necessidade de controlar permissões específicas para itens individuais. Se você usar permissões refinadas amplamente:

• Você gastará mais tempo gerenciando as permissões.

• O Microsoft Office SharePoint Server poderá desabilitar o cache de saída se um conjunto de sites contiver mais de 10.000 listas de Controle de Acesso (ACLs) exclusivas. Os usuários poderão obter desempenho mais lento quando tentarem acessar o conteúdo do site. Para obter mais informações sobre cache, consulte Armazenamento em cache no Office SharePoint Server 2007.

Assim como em qualquer servidor ou site, é importante seguir o princípio do menor privilégio quando se trata da autorização de acesso ao site: Os usuários devem ter somente os níveis de permissão que precisam usar. Comece pelos grupos padrão (como Membros, Visitantes e Proprietários), controlando as permissões no nível do site para garantir uma experiência de gerenciamento mais simplificada. Faça com que grande parte dos usuários sejam parte dos grupos Visitantes e Membros. Limite o número de pessoas no grupo Proprietários para apenas aqueles usuários aos quais você deseja permitir a alteração na estrutura do site ou nas configurações e aparência do site. Como padrão, os usuários no Grupo Membros podem contribuir no site, adicionar ou remover itens ou documentos, mas não podem alterar a estrutura do site ou as configurações e aparência do site. Você pode criar níveis de permissões e grupos adicionais do SharePoint, se for preciso controlar as ações dos seus usuários.

Se houver listas, bibliotecas, pastas, itens ou documentos em particular, com dados confidenciais que exigem uma segurança maior, você pode conceder permissões a um grupo específico ou a um determinado usuário. No entanto, não há como exibir todas as permissões específicas de listas, bibliotecas, pastas, itens ou documentos de um site. Isso significa que é difícil averiguar rapidamente quem tem permissões e quais são os objetos protegíveis, assim como também é difícil redefinir as permissões refinadas em massa.

Planejamento de herança de permissão

É mais fácil gerenciar as permissões quando há uma clara hierarquia de permissões e permissões herdadas. Fica mais difícil quando algumas listas em um site têm permissões refinadas aplicadas e quando alguns sites têm subsites com permissões exclusivas e algumas permissões herdadas. Dentro do possível, organize os sites, subsites, listas e bibliotecas, para que compartilhem do máximo de permissões. Separe os dados confidenciais em suas próprias listas, bibliotecas ou subsites.

Por exemplo, é muito mais fácil gerenciar um site que tem herança de permissões, como ilustrado na tabela a seguir.

Comparativamente, não é tão fácil gerenciar um site que tem herança de permissões, como ilustrado na tabela a seguir.

Scripts de subsites

Caso seu ambiente exija o mais alto nível de isolamento de conteúdo e de sites, poderá ser vantajoso projetar a estrutura do site do Office SharePoint Server de modo a minimizar os riscos associados ao uso de namespaces de URL contíguos. A configuração padrão de namespace de URL de site do Office SharePoint Server poderia permitir a ocorrência de um possível problema de scripts de subsite, em que um usuário mal-intencionado poderia executar ações em um site que estivessem fora do nível de permissão concedido ao usuário. O problema existe porque sites do Office SharePoint Server são limites de segurança, e qualquer número dos mesmos pode ser adjacente aos outros sob o mesmo nome de host. Como os navegadores da Web consideram apenas nomes de host (e não sites) como limites de segurança, em determinadas circunstâncias, conteúdo que tenha scripts residentes em um site do Office SharePoint Server poderia ser executado em outros sites que estivessem sob o mesmo nome de host.

O Office SharePoint Server autoriza o acesso ao conteúdo com base nos direitos e na associação de grupo de um usuário autenticado. Por esse motivo, um script que seja executado em nome de um usuário pode executar de fato qualquer ação que o usuário tenha permissão para executar. O problema em potencial é descrito no seguinte exemplo:

• O usuário A e o usuário B têm seus próprios conjuntos de sites do Office SharePoint Server: http://meus/sites/UsuárioA e http://meus/sites/UsuárioB.

• O Usuário A tem permissões de colaborador em seu próprio site, mas não tem permissões no site do Usuário B. Quando o Usuário A navega para o site do Usuário B, recebe um erro de Acesso Negado.

• No entanto, o Usuário A pode carregar um documento em seu site que contenha um script mal-intencionado e dar ao Usuário B acesso de leitura para ele. Se o Usuário B exibir o documento criado pelo Usuário A, o script mal-intencionado poderá ser executado sem aviso usando as credenciais do Usuário B. No contexto de muitos navegadores da Web disponíveis, o script não está ultrapassando um limite de segurança, e a execução do script não é considerada um evento entre domínios.

O problema existe porque o site do Office SharePoint Server do Usuário B e o site do Office SharePoint Server do Usuário A está sob o mesmo nome de host. Nessa estrutura de site, o Usuário B e o Usuário A precisam estar confiantes de que nenhum dos dois tentará executar um ataque de script. Se grupos de colaboradores não puderem confiar uns nos outros, seus sites deverão ser particionados por meio de nomes de host separados. O problema de scripts inspira cautela particularmente em cenários de colaboração do Office SharePoint Server, em vez de cenários de publicação na Internet ou de portal estruturado, porque o usuário mal-intencionado deve ter acesso de colaborador para executar um ataque de script de subsite.

À medida que o uso do Office SharePoint Server aumenta, principalmente o uso da intranet em grandes organizações, e à medida que vários usuários nas organizações se tornam colaboradores de alguma parte de uma implantação baseada em caminhos (por exemplo, http://my ou http://corp), a capacidade de confiar em todos os colaboradores do host pode representar um desafio. Isso se aplica particularmente a cenários em que é usada a criação de sites pessoais e em que os subsites passam a ter aninhamento muito profundo. Você pode projetar sua implantação do Office SharePoint Server para minimizar essas preocupações. Para obter informações sobre como projetar a arquitetura de informações, consulte Determinar a arquitetura de informações do site.

Para obter informações sobre como projetar conjuntos de sites, sites e subsites do Office SharePoint Server, consulte Determinar sites e subsites.

Para obter diretrizes de segurança adicionais, consulte o artigo sobre a Central de Recursos de Segurança para os Produtos e Tecnologias do SharePoint (em inglês) (https://go.microsoft.com/fwlink/?linkid=148056\&clcid=0x416) (em inglês).

Usando conjuntos de sites nomeados pelo host

Com o uso de conjuntos de sites nomeados pelo host, é possível aumentar a segurança do conteúdo e de sites, mediante o suporte à criação de vários conjuntos de sites no nível raiz em um único aplicativo Web. Por exemplo, os administradores de organizações de hospedagem podem usar conjuntos de sites nomeados pelo host para criar vários sites nomeados pelo domínio. O Windows SharePoint Services 3.0 dá suporte à criação de vários domínios em um único aplicativo Web. Isso permite colocar vários domínios, como http://UsuárioB.colab.minhacorp.com e http://UsuárioB.colab.minhacorp.com, em conjuntos de sites separados no mesmo aplicativo Web. No entanto, você precisa considerar as seguintes questões ao usar essa abordagem para gerenciar o problema de scripts de subsite:

• O uso de nomes de host amigáveis, como http://UsuárioB.colab.minhacorp.com, pode causar problemas de DNS, pois é preciso apontar para todos os nomes de host amigáveis para a implantação correta do Office SharePoint Server. Nomes de domínio totalmente qualificados podem atenuar o problema, com a habilitação do uso de entradas DNS, como *.colab.minhacorp.com.

• O Office SharePoint Server inclui suporte para criação e gerenciamento de conjuntos de sites pessoais baseados em caminho. A implantação de sites nomeados por cabeçalho do host pode causar sobrecarga operacional para o provisionamento de site. Para obter mais informações sobre a criação de sites de autoatendimento, consulte Configurar a criação de site pessoal.

Para obter mais informações sobre conjuntos de sites nomeados pelo host, consulte Planejar conjuntos de sites nomeados por host (Office SharePoint Server).

Movendo o conteúdo para um nome de host separado

Se houver conteúdo que você deseje mover para um nome de host separado, considere as seguintes diretrizes:

• Você pode mover pequenas quantidades de conteúdo, inclusive listas e bibliotecas de documentos, usando recursos de cliente, como Enviar para, Outro local, Abrir com Exibição do Explorer (para documentos) ou Exportar para Planilha (para listas).

• Para mover quantidades maiores de conteúdo, inclusive sites e conjuntos de sites, considere a opção de fazer backup do conteúdo e restaurá-lo. Para obter informações sobre backup e restauração do conteúdo, consulte Fazer backup e restaurar conjuntos de sites usando ferramentas internas (Office SharePoint Server 2007).

• Para quantidades de dados maiores, considere a opção de criar um novo conjunto de sites usando um nome de host diferente.

• Considere a opção de criar um caminho gerenciado no mesmo nível que o site do local original para hospedar o conjunto de sites. Definindo um caminho gerenciado, você pode especificar os caminhos no namespace de URL de um aplicativo Web que são usados para conjuntos de sites. Isso é importante porque o conteúdo do Office SharePoint Server usa caminhos relativos de servidor em muitos casos. Ao restaurar o conteúdo para um novo local, o Office SharePoint Server pode reparar o nome do host de uma URL, mas uma incompatibilidade de níveis nesse ponto pode resultar em falha da operação de restauração. Para obter mais informações sobre caminhos gerenciados, consulte Definir caminhos gerenciados.

Planilha

Na Planilha de segurança de conteúdo e site (https://go.microsoft.com/fwlink/?linkid=73135\&clcid=0x416) (em inglês), descreva a hierarquia do seu site e liste as permissões necessárias em cada nível da hierarquia e a herança de permissões.

Baixar este manual

Este tópico está incluído no seguinte manual baixável para facilitar a leitura e a impressão:

• Planejamento e arquitetura para o Office SharePoint Server 2007, parte 1

Consulte a lista completa de manuais disponíveis no Conteúdo baixável do Office SharePoint Server 2007.