Embed Size (px)
Citation preview
Práticas recomendadas para o uso de permissões refinadas
Este documento é fornecido "no estado em que se encontra". As informações e opiniões expressas neste
documento, incluindo URLs e outras referências a sites da Internet, podem ser alteradas sem aviso prévio.
Você assume o risco inerente à sua utilização.
Alguns dos exemplos descritos são fictícios e fornecidos para fins meramente ilustrativos. Nenhuma
associação ou conexão com entidades reais é intencional ou deve ser inferida.
Este documento não oferece a você quaisquer direitos legais sobre propriedade intelectual em qualquer
produto da Microsoft. Este documento pode ser copiado e usado para fins internos e de referência.
© 2010 Microsoft Corporation. Todos os direitos reservados.
Page 2
Práticas recomendadas para o uso de permissões refinadas
Autor: Sean Livingston, Gerente de Produtos, Grupo de Produtos do SharePoint Data de publicação: setembro de 2010
Resumo: este documento descreve as práticas recomendadas para o uso de permissões refinadas e explica como sua organização pode utilizá-las com os Produtos e Tecnologias do SharePoint® ou com o Microsoft® SharePoint® 2010.
Page 3
Conteúdo Conteúdo............................................................................................................................................................... 3
Visão geral do uso de permissões refinadas ......................................................................................................... 4
Visão geral do sistema de permissões do SharePoint .......................................................................................... 5
Níveis de permissão ........................................................................................................................................ 5
Grupos do SharePoint .................................................................................................................................... 6
Escopo ............................................................................................................................................................ 6
Objeto protegível............................................................................................................................................ 6
Herança .......................................................................................................................................................... 7
Acesso limitado .............................................................................................................................................. 8
ACL binária ...................................................................................................................................................... 9
Práticas recomendadas para evitar problemas comuns de limites de permissões refinadas ............................ 10
Muitos escopos em uma lista ....................................................................................................................... 10
Muitos membros em um escopo ................................................................................................................. 11
Hierarquia de escopo muito profunda ......................................................................................................... 11
Soluções recomendadas para problemas de desempenho de permissões refinadas ........................................ 12
Solução 1: Remover a permissão refinada e usar imposição de segurança somente no nível Web ........... 12
Limpeza de segurança ambiental .......................................................................................................... 13
Reestruturação da arquitetura de segurança ambiental ....................................................................... 14
Solução 2: Usar permissões refinadas por alterações na estrutura hierárquica ......................................... 14
Reestruturação da hierarquia do ambiente .......................................................................................... 15
Solução 3: Usar permissões refinadas por alterações na estrutura do escopo (somente 2010) ................. 15
Reestruturação do código de alteração da segurança dinâmica ........................................................... 16
Exemplo de arquitetura de ambiente ................................................................................................................. 17
Visão geral do ambiente ............................................................................................................................... 17
Design do fluxo de trabalho ......................................................................................................................... 18
Problemas de permissões refinadas............................................................................................................. 19
Resolução de problemas de permissões refinadas ...................................................................................... 20
Resumo ............................................................................................................................................................... 22
Page 4
Visão geral do uso de permissões refinadas Este artigo descreve o uso de permissões refinadas para Produtos SharePoint® 2010 (Microsoft® SharePoint®
Server 2010 e Microsoft® SharePoint® Foundation 2010) e Produtos e Tecnologias do SharePoint®
(Office SharePoint® Server 2007 e Windows SharePoint® Services 3.0) e analisa os problemas de desempenho
relacionados a permissões refinadas e as práticas recomendadas para a configuração de soluções que
contenham essas permissões.
Observação: convém usar permissões refinadas somente em casos comerciais necessários. Essas permissões
podem ser caras em termos de desempenho e supervisão operacional.
Pode-se evitar o uso de permissões refinadas da seguinte forma:
Evite ao máximo impedir a herança de permissões.
Use grupos com base em associação a diretórios para atribuir permissões.
Observação: não recomendamos o uso de grupos do SharePoint para atribuir permissões a sites,
pois isso causa um rastreamento completo do índice. Em vez disso, convém usar grupos de Domínio.
Atribua permissões no nível mais alto possível. Como parte dessa estratégia, considere as seguintes
técnicas:
o Separe os documentos que exigem permissões refinadas em bibliotecas de documentos
definidas para aceitarem cada grupo de permissões e mantenha essas bibliotecas em um site
ou conjunto de sites separado. Para obter mais informações sobre alterações hierárquicas,
consulte Solução 2: uso de permissões refinadas por alterações na estrutura hierárquica.
Observação: neste documento, os termos Web e site equivalem ao objeto SPWeb, enquanto
conjuntos de sites equivale ao objeto SPSite.
o Use níveis de publicação diferentes para controlar o acesso. Antes de publicar um documento,
é possível definir permissões avançadas e configurações de versões para usuários que só
podem aprovar itens na biblioteca de documentos.
o Para bibliotecas que não são compostas por documentos (listas), use os níveis de permissão
SegurançaDeLeitura e SegurançaDeGravação. Ao criarem uma lista, os proprietários podem
definir as permissões de nível de Item para acesso de leitura ou acesso de criação e edição.
Page 5
Se for necessário usar permissões refinadas, leve em conta as seguintes práticas recomendadas:
Não deixe muitos itens no mesmo nível hierárquico das bibliotecas de documentos, porque o tempo
necessário para processar os itens nos modos de exibição aumentará.
Use manipuladores de eventos para controlar a permissão de edição. Você pode ter um manipulador
de eventos que registra um evento usando os métodos SPEventReceiverType.ItemUpdating e
SPEventReceiverType.ItemUpdated e, depois, pode usar um código para controlar se a atualização
será permitida. Isso é extremamente eficiente, porque você pode tomar uma decisão de segurança
com base em quaisquer metadados de uma lista ou item sem afetar o desempenho de renderização
do modo de exibição. Para obter mais informações sobre manipuladores de eventos, consulte
Resolução de problemas de permissões refinadas.
Use o método AddToCurrentScopeOnly para atribuir associação do tipo Acesso Limitado em um
grupo do SharePoint. O principal elemento deste princípio é reestruturar a arquitetura de forma que
a associação de escopo não cause o recálculo da ACL na biblioteca de documentos pai e na Web. Para
obter mais informações sobre alterações hierárquicas, consulte Solução 3: uso de permissões
refinadas por alterações na estrutura do escopo (somente 2010).
Visão geral do sistema de permissões do SharePoint Esta seção descreve o sistema de escopo de permissões do SharePoint. Para obter mais informações sobre o
planejamento da segurança de sites, consulte:
Planejar permissões de site (SharePoint Server 2010) (http://technet.microsoft.com/pt-br/library/
cc262778.aspx)
Planejar permissões de site (SharePoint Foundation 2010) (http://technet.microsoft.com/pt-br/
library/cc287752.aspx)
Planejar a segurança do site (Office SharePoint Server) (http://technet.microsoft.com/pt-br/library/
cc262778(office.12).aspx)
Planejar a segurança do site (Windows SharePoint Services) http://technet.microsoft.com/pt-
br/library/cc287752(office.12).aspx (http://technet.microsoft.com/pt-
br/library/cc287752(office.12).aspx)
Níveis de permissão Um nível de permissão contém um conjunto de permissões individuais, como Exibir Itens ou Criar Alertas.
Níveis de permissão podem ser predefinidos ou criados pelo usuário. O conjunto de permissões pode ser
modificado mesmo dentro dos níveis de permissão predefinidos.
Page 6
Grupos do SharePoint Um grupo do SharePoint é um objeto presente em todo o conjunto de sites que pode conter outras entidades
de segurança, inclusive contas de usuários do Windows, usuários que não utilizam o Windows (por exemplo,
contas baseadas em formulários) e grupos do Active Directory.
Escopo O escopo é o limite de segurança de um objeto protegível e qualquer de seus filhos que não possuem um limite
de segurança separado definido. O escopo contém uma ACL (Lista de Controle de Acesso), mas, diferente das
ACLs NTFS, pode incluir entidades de segurança específicas do SharePoint. Os membros de uma ACL para um
escopo podem incluir usuários do Windows, usuários que não utilizam o Windows (como contas baseadas em
formulários de Produtos e Tecnologias do SharePoint ou contas baseadas em declarações dos Produtos do
SharePoint 2010), grupos do Active Directory ou grupos do SharePoint.
Não existe um número máximo de escopos que podem ser criados em um escopo pai. No entanto, nos
Produtos e Tecnologias do SharePoint, após a criação de 1.000 escopos, é usado um caminho de código que
exige viagens de ida e volta adicionais do Microsoft® SQL Server para analisar os escopos antes de renderizar
um modo de exibição. Havendo 1.000 ou menos escopos, é necessário apenas uma viagem de ida e volta.
Nos Produtos do SharePoint 2010, o limite de escopos retornados antes da mudança para outro algoritmo
tem como base um limite de aceleração de consulta, com valor padrão de 5.000. No entanto, esse valor,
mesmo em seu padrão, pode ser alto o suficiente para prejudicar significativamente o desempenho.
Os Produtos do SharePoint 2010 têm um novo método chamado
SPRoleAssignmentCollection.AddToCurrentScopeOnly, pelo qual pode ocorrer a atribuição de funções.
Para obter mais informações sobre a atribuição de funções, consulte
SPRoleAssignmentCollection.AddToCurrentScopeOnly (http://msdn.microsoft.com/pt-br/
library/microsoft.sharepoint.sproleassignmentcollection.addtocurrentscopeonly.aspx).
Objeto protegível Objeto protegível é aquele que pode receber a atribuição de uma ACL. Nos Produtos e Tecnologias do
SharePoint, pode-se usar a interface IsecurableObject e, nos Produtos do SharePoint 2010, deve-se usar
a classe SPSecurableObject. Para obter mais informações sobre objetos protegíveis, consulte Interface
ISecurableObject (http://msdn.microsoft.com/pt-br/library/microsoft.sharepoint.isecurableobject.aspx) ou
Classe SPSecurableObject (http://msdn.microsoft.com/pt-br/library/
microsoft.sharepoint.spsecurableobject.aspx).
Page 7
Herança Quando um objeto protegível não tem um escopo exclusivo, ele herda o escopo do seu pai. Quando isso
acontece, nenhum escopo é criado para esse objeto. Em vez disso, sempre que ocorre uma verificação de
segurança, é feita a comparação apenas em relação ao objeto pai. No ambiente mais simples, este escopo
fica na Web raiz do conjunto de sites que contém o item. Quando um item ou contêiner é alterado para ter
associação exclusiva, sua herança é interrompida, o que significa que um novo escopo é criado para o item e,
por padrão, para todos os filhos que herdam seus escopos de permissões.
O diagrama abaixo mostra uma hierarquia de objetos de uma biblioteca de documentos, na qual todos os
objetos, exceto um, herdam seus escopos de seus pais. Cada hexágono dourado numerado representa um
escopo de permissões. Todos os objetos filhos de um contêiner herdam esse escopo pai, exceto quando
possuem seu próprio escopo de permissões exclusivo.
Page 8
Acesso limitado Quando uma entidade de segurança é adicionada ao escopo de um item com permissões exclusivas, ela é
imediatamente acrescentada ao nível de permissão de Acesso Limitado de cada escopo de permissões
exclusivo da hierarquia acima do item, até que uma Web pai com permissões exclusivas seja localizada.
O motivo da inclusão do usuário nos escopos com Acesso Limitado é permitir acesso suficiente ao objeto
hierarquicamente acima do item com permissão exclusiva, de forma que o OM (Modelo de Objeto), as
páginas mestras e a navegação possam ser renderizados quando o usuário tentar navegar até esse item.
Sem as permissões de Acesso Limitado nos escopos pais, o usuário não conseguiria navegar com êxito ou
abrir o item que tem permissões exclusivas.
O diagrama abaixo mostra como a profundidade hierárquica dos escopos pode afetar a quantidade de
trabalho necessária para adicionar usuários com Acesso Limitado aos escopos pais. Quanto maior for o
número de escopos exclusivos acima do item, até e incluindo a Web com permissão exclusiva, maior será o
número de acréscimos necessários. O diagrama mostra uma representação simplificada de uma estrutura
física com escopos exclusivos definidos em cada nível da Web, descendo até itens individuais. Como no
diagrama anterior, cada hexágono dourado numerado representa um escopo de permissões exclusivas, e
todos os objetos filhos desse contêiner herdam desse escopo, exceto quando possuem seu próprio escopo
de permissões exclusivas. A cadeia de promoção de Acesso Limitado é mostrada com setas vermelhas.
Page 9
O diagrama também inclui um conjunto de escopos exclusivos junto com os acréscimos de associações de
Acesso Limitado que devem ocorrer em cada escopo pai, representados por caixas separadas dentro do
escopo. Não é necessária nenhuma programação adicional para adicionar escopos exclusivos sempre que
uma entidade de segurança for adicionada a um escopo de objeto com permissões exclusivas situado abaixo
de uma Web com permissões exclusivas.
Quando uma entidade de segurança com o nível de permissões de Acesso Limitado é adicionada a um escopo
pai, não é feita nenhuma verificação para examinar se ela já está presente nesse escopo. Uma entidade de
segurança que já tenha acesso ao escopo pai é adicionada novamente com permissões de Acesso Limitado,
independentemente de suas permissões existentes no escopo pai.
Quando uma entidade de segurança é removida do nível de permissão de Acesso Limitado de um escopo pai,
cada instância dessa entidade dentro de cada escopo filho é removida do nível de permissão de Acesso
Limitado, independentemente de a entidade de segurança ter Acesso Limitado ou um conjunto mais amplo
de permissões nos escopos filhos.
ACL binária Uma ACL binária realiza comparações rápidas de um token de usuário para determinar se o usuário teria
acesso ao objeto coberto pelo escopo. Sempre que a associação de um escopo é alterada, uma ACL binária
é calculada, inclusive quando um novo membro com acesso limitado é adicionado. A ACL binária leva mais
tempo para fazer o cálculo à medida que a associação aumenta, e o acesso aos objetos é bloqueado até que
a ACL possa ser recalculada.
Embora não exista limite de tamanho explícito em uma ACL binária além do tamanho máxima de uma coluna
de imagem no SQL Server, alguns serviços não aceitam uma ACL maior que 64 KB. Nesse caso, o número de
entidades de segurança na ACL binária pode aumentar muito, mas deve ser limitada devido a questões de
desempenho e interoperabilidade. Para obter mais informações limites de tamanhos da coluna de imagem no SQL
Server, consulte ntext, text e image (Transact-SQL) (http://msdn.microsoft.com/pt-br/library/ms187993.aspx).
Page 10
Práticas recomendadas para evitar problemas comuns de limites de permissões refinadas Ao trabalhar com permissões refinadas, às vezes encontramos inadvertidamente limites que impedem a
resolução de permissões.
Muitos escopos em uma lista Existe um limite interno de 50.000 escopos por lista ou biblioteca de documentos. Após 50.000 escopos,
é proibido incluir novos escopos em uma determinada lista ou biblioteca de documentos.
Nos Produtos SharePoint 2010, o limite interno de escopos pode ser modificado usando-se o script
Windows PowerShell.
Para modificar o limite interno de escopos para menos de 50.000 escopos
1. Verifique os seguintes requisitos mínimos estão sendo respeitados: Consulte Add-SPShellAdmin
(http://technet.microsoft.com/pt-br/library/ff607596.aspx).
2. No menu Iniciar, clique em Todos os Programas.
3. Clique em Produtos do Microsoft SharePoint 2010.
4. Clique em Shell de Gerenciamento do SharePoint 2010.
5. No prompt de comando do Windows PowerShell, digite a seguinte sintaxe:
$webapp = Get-SPWebApplication http://serverName
$webapp.MaxUniquePermScopesPerList
$webapp.MaxUniquePermScopesPerList = <Número do limite de escopos>
Geralmente, no entanto, o limite real é muito menor que 50.000 se existem muitos escopos no mesmo nível
hierárquico. Isso ocorre porque as verificações de exibição de itens abaixo desse nível hierárquico devem ser
feitas em relação a todos os escopos acima dele. Esse limite pode fazer o número real de escopos permitidos
em uma consulta específica ser reduzido para 1.000 ou 2.000.
Práticas recomendadas:
Só defina escopos exclusivos em objetos pais, como pastas.
Não crie um sistema com muitos objetos com permissões exclusivas abaixo de um objeto com muitos
escopos.
Se sua empresa precisa de mais de 50.000 itens com permissões exclusivas em uma lista ou biblioteca de
documentos, mova alguns itens para outra lista ou biblioteca de documentos.
Page 11
Muitos membros em um escopo Conforme descrito acima, uma ACL binária é calculada sempre que ocorre alteração na associação do escopo,
inclusive quando um novo membro com acesso limitado é adicionado. Como o número de associações do
escopo aumenta, o tempo necessário para recalcular a ACL binária também é maior.
No entanto, o problema pode piorar, pois as adições de usuários a um escopo exclusivo de objetos filhos
causarão a atualização de seus escopos pais com os novos membros de Acesso Limitado, mesmo que isso, ao
final, não cause nenhuma alteração na associação do escopo pai. Quando isso acontece, a ACL binária do(s)
escopo(s) pai(s) também deve ser recalculada, ao custo de um tempo de processamento maior, mesmo que,
no final das contas, isso tudo resulte na mesma ACL.
Prática recomendada:
Use associações de grupo em vez de associações de usuários individuais nos escopos. Por exemplo, se um
único grupo pode ser usado no lugar de 1.000 usuários, o escopo terá menos 999 entradas de associação,
assim como seus escopos pais, que serão atualizados com direitos de Acesso Limitado para aquele grupo
único, e não para todos os 1.000 usuários individuais com direitos de Acesso Limitado. Isso ainda ajuda a
aumentar a velocidade de imposição dos direitos de Acesso Limitado e recálculo da ACL nos objetos de
escopo pai.
Importante: usar um grupo do SharePoint causará um rastreamento completo do índice. Se possível, use um
grupo de domínio.
Hierarquia de escopo muito profunda Como indicado acima, a profundidade hierárquica dos escopos pode afetar a quantidade de trabalho
necessária para adicionar usuários com Acesso Limitado aos escopos pais. Quanto maior for o número de
escopos exclusivos acima do item, até e incluindo a Web com permissão exclusiva, maior será o número de
acréscimos necessários. Se a hierarquia do escopo for muito profunda, as alterações nas associações do
escopo podem demorar muito, já que cada alteração no item de escopo mais profundo terá que atualizar
iterativamente os escopos pais com uma adição de associação para o usuário ou grupo com direitos de
Acesso Limitado adicionado explicitamente. Além disso, haverá aumento no número de ACLs binárias que
precisam ser recalculadas, com um impacto correspondente no desempenho.
Prática recomendada:
Reduzir os números de objetos pais com permissões exclusivas, diminuindo, assim, o número de escopos
que precisam ser atualizados com membros de Acesso Limitado sempre que qualquer escopo de objeto filho
for alterado.
Page 12
Soluções recomendadas para problemas de desempenho de permissões refinadas As seguintes soluções podem ajudar a mitigar problemas de desempenho relacionados especificamente ao
uso extensivo de permissões refinadas. Cada uma das capas abaixo muda para a segurança de ambiente,
hierarquia de objeto ou código personalizado que está contribuindo para o problema de desempenho
relacionado à permissão refinada. Cada solução começará com o seguinte exemplo de ambiente no qual
uma única Web contém várias bibliotecas de documentos, cada uma com um número grande de objetos
filhos com permissões exclusivas.
Solução 1: Remover a permissão refinada e usar imposição de segurança somente no nível Web Para modificar a arquitetura dos ambientes de forma que eles não precisem mais de permissões refinadas,
pode-se implementar um processo de limpeza do ambiente e, em seguida, o número de itens do escopo
pode ser ajustado para melhorar a escalabilidade do ambiente em longo prazo. As recomendações a seguir
descrevem as alterações de limpeza do ambiente e segurança de arquitetura necessárias para efetivar
essa solução.
Page 13
Limpeza de segurança ambiental Quando um usuário é removido do escopo do nível Web, o OM interno deve remover o usuário de todos os
escopos abaixo dele. No entanto, remover usuários individuais para limpar permissões existentes é um
processo demorado. Em vez disso, primeiro remova cada escopo exclusivo de nível de item individual para
que o item seja definido para herdar permissões de seu objeto pai. Isso levará menos tempo,
comparativamente, que tentar remover os usuários primeiro, porque será necessário agir em somente um
escopo do item.
Importante: se a Web atual não estiver na raiz do conjunto de sites e for definida para herdar suas
permissões de sua Web pai, todos os escopos exclusivos abaixo dela serão removidos, e todas as associações
de Acesso Limitado serão substituídas de uma só vez com uma única viagem de ida e volta do SQL Server.
Depois que todos os escopos de nível de item forem removidos, as associações de escopo individuais no
escopo de nível Web poderão ser substituídas por uma ou mais associações de grupo para permitir o acesso.
Page 14
Reestruturação da arquitetura de segurança ambiental Após a remoção de permissões refinadas e escopos existentes, o plano de arquitetura de longo prazo deve
prever a manutenção de um escopo único somente no nível Web. O diagrama abaixo mostra como isso
poderia ser estruturado de forma que permaneça somente o escopo de nível Web. O principal requisito da
arquitetura é não ter muitos itens no mesmo nível hierárquico das bibliotecas de documentos, porque o
tempo necessário para processar os itens nos modos de exibição aumentará. Como prática recomendada, o
número máximo de itens ou pastas em qualquer nível da hierarquia deve ser aproximadamente 2.000 itens.
Se for necessário alterar ainda mais a arquitetura, considere movimentar bibliotecas de documentos para
outras Webs ou conjuntos de sites. O número de bibliotecas de documentos também pode ser alterado para
suportar melhor as necessidades da empresa e atender recomendações baseadas na taxonomia ou público-
alvo do conteúdo armazenado.
Solução 2: Usar permissões refinadas por alterações na estrutura hierárquica Para mudar a arquitetura do ambiente, de forma que ele ainda utilize permissões refinadas, mas sem causar
atualizações excessivas ou dimensionamento de um único escopo Web, considere transferir bibliotecas de
documentos com diferentes tipos de proteção para outras Webs.
Page 15
Reestruturação da hierarquia do ambiente No diagrama abaixo, a arquitetura física foi modificada de forma que cada biblioteca de documentos fique
em uma Web com permissões exclusivas. Além disso, quando é necessário preservar a permissão refinada do
nível de item, a prática recomendada é limitar a aproximadamente 2.000 o número acumulado de entidades
de segurança que receberão acesso, embora esse limite não seja fixo. Dessa forma, a associação real de
cada Web, incluindo todos os usuários com Acesso Limitado, não deve ser superior a aproximadamente
2.000 usuários, a fim de evitar que cada escopo de nível Web cresça muito.
O número de filhos com escopo exclusivo não é um problema significativo, podendo aumentar e atingir
grandes quantidades; porém, o número de entidades a serem adicionadas como acesso limitado na cadeia
de escopos até a primeira Web com permissão exclusiva será um fator de limitação.
Por fim, embora não seja especificamente um problema de permissão refinada, a estrutura de pastas
deve assegurar que nenhum nível hierárquico da biblioteca de documentos ultrapasse aproximadamente
2.000 itens. Esse limite pode ajudar a garantir um bom desempenho dos modos de exibição solicitados pelos
usuários.
Solução 3: Usar permissões refinadas por alterações na estrutura do escopo (somente 2010) Para modificar a arquitetura do ambiente, de forma que ele ainda utilize permissões refinadas, mas sem causar
atualizações excessivas ou dimensionamento de um único escopo Web, considere usar outro processo para
proteger itens. Isso é aplicável principalmente se o excesso de escopos exclusivos foi causado por um processo
automatizado, como um manipulador de eventos ou fluxo de trabalho que modificou dinamicamente as
permissões de objetos. Nesse caso, recomenda-se alterar o código do processo que estava criando os escopos
de segurança exclusivos.
Page 16
Reestruturação do código de alteração da segurança dinâmica No diagrama abaixo, a arquitetura do escopo foi modificada de forma que a associação do escopo não cause
o recálculo da ACL na biblioteca de documentos pai e na Web. Conforme mencionado acima, a associação
real da Web, incluindo todos os membros com Acesso Limitado, não deve ser superior a aproximadamente
2.000 usuários, a fim de evitar que o escopo de nível Web cresça muito. Nesse caso, no entanto, com a
implementação de um novo grupo do SharePoint para conter todos os membros que deveriam ter direitos de
Acesso Limitado, o escopo não crescerá muito. Quando os usuários são adicionados a escopos individuais no
nível Web por meio do novo método SPRoleAssignmentCollection.AddToCurrentScopeOnly dos Produtos
SharePoint 2010, eles também podem ser adicionados, através de código adicional, ao novo grupo que já foi
estabelecido como detentor de direitos de Acesso Limitado no nível Web e biblioteca de documentos.
Conforme mencionado, quando é necessário preservar a permissão refinada do nível de item, a prática
recomendada é limitar a aproximadamente 2.000 o número acumulado de entidades de segurança que
receberão acesso, embora esse limite não seja fixo. Assim, quando esse número aumenta, o tempo
necessário para recalcular a ACL binária também aumenta. Se a associação de um escopo for alterada, a ACL
binária deverá ser recalculada. No entanto, as adições de usuários a um escopo exclusivo de item filho
resultarão na atualização de seus escopos pais com os novos membros de Acesso Limitado, mesmo que isso,
no final das contas, não cause qualquer alteração na associação do escopo pai. Quando isso acontece, a ACL
binária do(s) escopo(s) pai(s) também deve ser recalculada.
Assim como na solução anterior, o número de filhos com escopo exclusivo não é um problema significativo,
podendo aumentar e atingir grandes quantidades. Porém, o número de entidades a serem adicionadas como
acesso limitado na cadeia de escopos até a primeira Web com permissão exclusiva será um fator de limitação.
Page 17
Exemplo de arquitetura de ambiente Esta seção descreve um exemplo de ambiente que apresentava problemas graves relacionados a uma
confluência de problemas de permissões refinadas e aborda a combinação de soluções usadas para corrigi-los.
Visão geral do ambiente Um sistema de gerenciamento de conhecimento baseado no SharePoint Server 2007 continha dois conjuntos
de sites, cada um com uma única Web, Contoso-Provisório e Contoso-Produção. No Contoso-Provisório as
versões iniciais eram publicadas, e os fluxos de trabalho interagiam com os documentos. Contoso-Produção
era o destino final de cada documento aprovado e o repositório de todo o conteúdo aprovado.
Os documentos poderiam ser atribuídos a um de vários tipos de conteúdo que trazem o objetivo pretendido do
documento (como planos de projeto ou guias de solução de problemas). Além disso, os documentos eram
classificados dentro de domínios de tecnologia (que poderiam se desdobrar em centenas ou mais
especificidades) e por várias disciplinas (como gerenciamento de projetos ou operações). O conjunto de sites de
publicação provisório continha uma biblioteca de documentos por disciplina, cada uma com uma hierarquia de
pastas ainda mais específicas para cada domínio tecnológico. Ao criarem um novo documento, os usuários
deveriam, primeiro, selecionar uma biblioteca de disciplina e uma pasta de domínio tecnológico específica.
O diagrama abaixo mostra uma representação simplificada da estrutura física original da Web, na qual cada
hexágono dourado numerado representa um escopo de permissões exclusivas, e todos os objetos filhos desse
contêiner herdam desse mesmo escopo, exceto quando possuem seu próprio escopo de permissões exclusivas.
Page 18
Cada combinação de tipo de conteúdo, domínio tecnológico e disciplina teria um revisor não repetido, que seria
um especialista na tecnologia ou disciplina. A biblioteca de documentos deveria conter um grande número de
itens durante suas operações de fluxo de trabalho, que alteravam dinamicamente o revisor atribuído e a
segurança do item. Depois que o documento recebia sua revisão final, era copiado para um local baseado no
Contoso-Produção correspondente, onde permanecia inalterado como uma versão publicada e disponível para
todos os funcionários da empresa.
Para obter informações sobre o tipo de conteúdo e o planejamento do fluxo de trabalho, consulte:
Tipo de conteúdo e planejamento do fluxo de trabalho (SharePoint Server 2010)
(http://technet.microsoft.com/pt-br/library/cc262735.aspx)
Planejamento de tipos de conteúdo (SharePoint Foundation 2010) (http://technet.microsoft.com/
pt-br/library/ff607870.aspx)
Planejamento de tipos de conteúdo (Office SharePoint Server) (http://technet.microsoft.com/pt-
br/library/cc262735(office.12).aspx)
Planejamento de tipos de conteúdo (Windows SharePoint Services)
(http://technet.microsoft.com/pt-br/library/cc287765(office.12).aspx)
Design do fluxo de trabalho Quando o processo do fluxo de trabalho era iniciado, o autor de um documento era impedido de acessá-lo,
para que outras pessoas pudessem revisá-lo sem que o autor fizesse alterações ao mesmo tempo. Para cada
etapa sucessiva do fluxo de trabalho, os usuários que tinham acesso ao documento eram impedidos de
acessá-lo, e os revisores do próximo estágio do fluxo de trabalho tinham o acesso liberado.
O processo do fluxo de trabalho usava um fluxo de trabalho codificado e um manipulador de eventos
personalizado, que funcionavam juntos. Quando um item era alterado na biblioteca de documentos, era
inicialmente controlado pelo manipulador de eventos personalizado, que poderia alterar permissões e iniciar
uma nova instância de fluxo de trabalho. Tanto o fluxo de trabalho quanto o manipulador de eventos mudavam
as permissões do arquivo específico que estava sendo atualizado, de forma que cada item recebesse um escopo
de permissões exclusivo. Essa mudança nas permissões significava que apenas um único usuário ou pequeno
subconjunto de usuários (isto é, os revisores daquela etapa) tinham acesso ao item de cada vez. A etapa final
do fluxo de trabalho, depois que o documento era totalmente aprovado, era copiá-lo para o local equivalente
no Contoso-Produção como uma nova versão publicada do documento, com permissões herdadas da Web pai.
Page 19
Problemas de permissões refinadas O projeto de ambiente e fluxo de trabalho foi testado com êxito durante a fase de desenvolvimento, mas
agora apresentava problemas graves de desempenho, com usuários sofrendo atrasos de um a dezenas de
minutos antes de conseguirem cumprir suas tarefas. O teste usou apenas centenas de contas de teste, mas,
quando o projeto foi disponibilizado e anunciado como ferramenta de coleta de conhecimento obrigatória
para toda a empresa, sua utilização aumentou para mais de 15.000 usuários trabalhando cumulativamente
em mais de 30.000 documentos. Os problemas de desempenho relatados impediram que uma parte
significativa da empresa conseguisse usar o novo sistema de gestão do conhecimento, que deveria acomodar
mais de 60.000 usuários.
Quando as permissões eram alteradas no fluxo de trabalho, era criado um escopo de permissões para cada
item individual. Seguindo os requisitos do nível de permissão de Acesso Limitado conforme descrito
anteriormente, cada entidade de segurança exclusiva era adicionada com Acesso Limitado aos vários escopos
de permissão exclusivos na hierarquia acima do item, até que uma Web com permissão exclusiva fosse
localizada. Portanto, quanto mais escopos exclusivos acima do item com permissão exclusiva, mas abaixo da
Web com permissão exclusiva, a mais escopos com Acesso Limitado a entidade de segurança era adicionada.
É importante lembrar que o problema não ocorria devido ao alto número de escopos exclusivos criados
dentro da Web raiz dos conjuntos de sites, mas porque o número real de entidades de segurança exclusivas
dentro do escopo de nível Web aumentou para mais de 15.000 usuários. Cada usuário adicionado a qualquer
escopo de permissões exclusivo abaixo da Web também era adicionado ao próprio escopo da Web, o que
causava um recálculo da ACL binária para cada adição.
Devido ao tamanho do escopo de nível Web combinado à frequência de recálculo da ACL binária, podem
ocorrer bloqueios em vários procedimentos armazenados no SQL Server. Sempre que um item com herança
rompida tinha seu escopo de associação alterado, ele fazia com que cada membro do escopo fosse adicionado
como detentor da associação de usuário de Acesso Limitado no escopo de nível Web. Além disso, sempre que a
associação do escopo Web era atualizada com membros existentes ou novos, inclusive para Acesso Limitado,
isso causava um recálculo da ACL binária do escopo do nível Web. Como o escopo do nível Web continha mais
de 15.000 entidades de segurança, o recálculo era demorado. Durante a operação, o objeto não podia ser
acessado, e os usuários finais sofriam com dificuldades de logon intermitentes.
Page 20
Resolução de problemas de permissões refinadas As soluções mencionadas anteriormente foram consideradas parte do processo de mitigação de problemas
de desempenho relacionados a permissões refinadas, com planos de curto e longo prazo. A decisão de curto
prazo era reorganizar o fluxo de trabalho para não definir mais por permissão refinada de item, e a estrutura
do ambiente permaneceu com a mesma hierarquia. Os escopos de permissão refinada individuais foram
removidos, inicialmente tentando-se remover cada usuário do escopo Web ou escopos de nível de item, mas,
como o desempenho continuava insatisfatório, iniciou-se um processo de remoção de cada escopo de item
fazendo o item herdar permissões de seu pai. Além disso, foi feito um rebalanceamento de conteúdo para
evitar que muitos itens fossem exibidos em um nível específico da hierarquia.
O manipulador de eventos foi modificado para impor acesso de formulário ou leitura para quem não estava
atribuído como revisor, impedindo modificações em documentos ou fluxos de trabalho. Essa abordagem não
limitou quem poderia exibir itens, porque não há outra maneira a não ser o uso de escopos para restringir
com segurança a exibição, mas ela poderia ser usada para evitar modificações em documentos ou fluxos de
trabalho, como, por exemplo, evitar que o autor modificasse o documento enquanto este estivesse no ciclo de
revisão. Depois que os escopos de segurança de itens individuais foram removidos, e o fluxo de trabalho e o
manipulador de eventos atualizados foram instalados, os usuários puderam usar o ambiente, sem a imposição
de segurança de nível de item individual com problemas de desempenho.
O diagrama abaixo mostra uma representação simplificada da estrutura física original da Web após a
remoção do escopo de segurança, na qual cada hexágono dourado numerado representa um escopo de
permissões exclusivas, e todos os objetos filhos desse contêiner herdam desse mesmo escopo, exceto
quando possuem seu próprio escopo de permissões exclusivas.
Page 21
Uma solução de prazo mais longo planejada com os Produtos e Tecnologias do SharePoint seria dividir o
conteúdo em diferentes Webs, de forma que as permissões refinadas continuassem a ser usadas, mas com
impacto geral limitado a um grupo muito menor de mudanças.
O diagrama abaixo mostra uma representação simplificada da estrutura física original do conteúdo após a
divisão em diferentes Webs, na qual cada hexágono dourado numerado representa um escopo de
permissões exclusivas, e todos os objetos filhos desse contêiner herdam desse mesmo escopo, exceto
quando possuem seu próprio escopo de permissões exclusivas.
O diagrama mostra o projeto de escopo lógico e destaca os limites de acréscimo de entidades de segurança
exclusivas a cada escopo da Web se as permissões refinadas fossem reabilitadas após a transferência para
outras Webs. Note que, embora ainda permanecesse um grande número de itens com permissões exclusivas,
seria resolvido o principal problema do número excessivo de entidades de segurança em um escopo.
Page 22
Por fim, foi levado em conta que a eventual mudança para Produtos do SharePoint 2010 traria novos
recursos para o projeto de fluxo de trabalho, especificamente a capacidade de atribuir dinamicamente uma
permissão refinada, usando o método SPRoleAssignmentCollection.AddToCurrentScopeOnly para designar
uma associação apenas ao escopo individual de cada item e, depois, concedendo a um grupo do SharePoint,
que contém essa associação, Acesso Limitado à Web pai. Esse processo permitiria que a permissão refinada
fosse implementada via fluxo de trabalho e/ou manipulador de eventos sem prejudicar o desempenho.
Resumo Este documento descreve práticas recomendadas para que a sua organização utilize permissões refinadas,
examinando os problemas de desempenho que podem ocorrer. Além disso, são analisadas estratégias e
processos para mitigar problemas caso o ambiente esteja sendo prejudicado por uso indevido ou pela
quantidade de permissões refinadas. Por fim, ele mostra um exemplo de ambiente que apresentou
problemas de uso indevido de permissões refinadas e o processo usado para corrigir a situação.
