ATUALIZAÇÃO 11/03/08: Certifique-se de ler o comentário excelente e detalhado da Dessie Lunsford para este post.

Eu estive trabalhando em um projeto de edição de tecnologia secreta para um livro de up-coming e ele faz referência a Esta entrada de blog por Tyler Butler no blog do MSDN ECM. Esta é a primeira vez que li pessoalmente uma definição clara do significado do acesso limitado. Aqui é a carne da definição:

No SharePoint, usuários anônimos’ direitos são determinados pelo nível de permissão de acesso limitado. Acesso limitado é um nível de permissão especial que não pode ser atribuído a um usuário ou grupo diretamente. A razão de existir é porque se você tem uma biblioteca ou subsite que tem quebrado a herança de permissões, e você dá um acesso de usuário/grupo para apenas essa biblioteca/subsite, para visualizar seu conteúdo, o usuário/grupo deve ter algum acesso à web raiz. Caso contrário, o usuário/grupo será incapaz de procurar o biblioteca/subsite, mesmo que lá têm direitos, Porque há coisas na web raiz que são necessários para processar o site ou biblioteca. Por conseguinte, Quando você dá a um permissões de grupo apenas para um subsite ou biblioteca que é quebrar a herança de permissões, SharePoint dará automaticamente acesso limitado a esse grupo ou usuário na web raiz.

Esta questão vem à tona agora e depois nos fóruns do MSDN e sempre fui curioso (Mas não é curioso o suficiente para descobrir antes de hoje :)).

</fim>

Subscreva ao meu blog.

Siga-me no Twitter em http://www.twitter.com/pagalvin

Em um sinal de que a Computação Social está começando a decolar com o SharePoint, Vejo um aumento do número de questões do tipo Meu Site. Uma pergunta comum é algo assim:

"Eu sou um administrador e eu preciso ser capaz de acessar todos os meu Site. Como eu faço isso?"

O truque aqui é que cada meu Site é seu próprio conjunto de sites. Segurança do SharePoint é normalmente administrada no nível de coleção do site e isso confunde muitos um administrador do SharePoint. Normalmente, Ela já tem acesso ao configurar a segurança em geral"" conjuntos de sites e pode não perceber que isto não funciona automaticamente para meus Sites.

Conjuntos de sites vivem coletivamente dentro de um recipiente maior, Qual é o aplicativo da web. Administradores de fazenda podem pode configurar a segurança no nível do aplicativo web e isto é como administradores podem se conceder acesso a qualquer conjunto de sites no aplicativo web. Esta entrada de blog descreve uma das minhas experiências pessoais com diretivas de aplicativo da web. Defini uma diretiva de aplicativo web por acidente: http://paulgalvin.spaces.live.com/Blog/cns!1CC1EDB3DAA9B8AA!255.entry.

Diretivas de aplicativo da Web podem ser perigosas e sugiro que eles ser usados com moderação. Se eu fosse um admin (e graças a Deus eu não sou), Gostaria de criar uma conta separada do AD chamada algo como "administrador do SharePoint Web App" e dar uma conta a função de segurança de aplicativo da web precisa. Eu não iria configurar esse tipo de coisa para a fazenda regular admin ou administradores de coleção de site individual. Isso tenderá a esconder problemas potenciais, porque a função de aplicativo da web substitui quaisquer configurações de segurança de nível inferiores.

</fim>

Subscreva ao meu blog.

Siga-me no Twitter em http://www.twitter.com/pagalvin

ATUALIZAÇÃO (02/29/08): Este novo projeto codeplex parece fornecer um método para proteção de colunas individuais: http://www.codeplex.com/SPListDisplaySetting. Se você tem alguma experiência em trabalhar com ele, por favor, deixe um comentário.

Cartazes Fórum freqüentemente uma pergunta como esta: "Tenho uma visão de gerente e e uma visão pessoal de uma lista. Como para proteger a vista do gerente para que a equipe não pode usá-lo?"

Eles também freqüentemente uma perguntam relacionada: "Quero proteger uma coluna de metadados específicos, de forma que somente os gestores podem editar essa coluna enquanto outros não podem vê-lo."

Estas respostas se aplicam a ambos WSS 3.0 e musgo:

• SharePoint não oferece suporte out-of-the-box para proteger visualizações.
• SharePoint não oferece suporte out-of-the-box para colunas de segurança.

Existem várias técnicas podem seguir para encontrar estes tipos de requisitos de segurança. Eis o que penso:

• Usar a segurança de nível de item de out-of-the-box. Exibições sempre honrar a configuração de segurança em nível de item. Receptores de evento e/ou fluxo de trabalho pode automatizar a atribuição de segurança.
• Use pontos de vista pessoais para "privilegiado" Modos de exibição. Estas são bastante fáceis de configurar. No entanto, devido à sua "personal" natureza, Estes precisam ser configurados para cada usuário. Use a configuração de segurança padrão para impedir que alguém criando uma visão pessoal.
• Usar uma web part de exibição de dados e implementar algum tipo de solução de aparamento de segurança AJAXy.
• Rolar sua própria funcionalidade de exibição de lista e incorporar o aparamento de segurança no nível de coluna.
• Modificar as formas de entrada de dados e usar JavaScript em conjunto com o modelo de segurança para implementar o aparamento de segurança de nível de coluna.
• Usar um formulário do InfoPath para entrada de dados. Implementar o aparamento de segurança de nível de coluna através de chamadas de serviço web para SharePoint e condicionalmente ocultar campos conforme necessário.
• Rolo de sua própria função de entrada de dados do ASP.NET que implementa o aparamento de segurança em nível de coluna.

Nenhuma dessas opções são realmente é ótima, Mas há pelo menos um caminho a seguir, se você precisa, mesmo se é difícil.

OBSERVAÇÃO: Se fores por qualquer um desses caminhos, Não se esqueça de "ações-> Abrir com Windows Explorer". Você quer ter certeza de que você teste com esse recurso para certificar-se de que ele não funciona como uma "porta dos fundos" e derrotar o seu esquema de segurança.

Se você tiver outras idéias para ou experiências com fixar colunas ou pontos de vista, por favor correio eletrónico a mim ou deixe um comentário e eu vou atualizar esta postagem conforme apropriado.

</fim>

Subscreva ao meu blog.

ATUALIZAÇÃO: Eu postei esta pergunta para MSDN aqui (http://forums.microsoft.com/Forums/ShowPost.aspx?PostID=2808543&SiteID=1&mode=1) e Michael Washam da Microsoft respondeu com uma resposta concisa.

Eu criei um web service para atuar como um Fachada do BDC-amigável para uma lista do SharePoint. Quando usei isto do meu ambiente de desenvolvimento, funcionou muito bem. Quando isso migrei para um novo servidor, Eu encontrei este erro:

Aqui é a linha 69:

usando (SPSite site = new SPSite t: Microsoft.SharePoint.SPSite("http://localhost/sandbox"))

Eu tentei diferentes variações na URL, inclusive usando o nome do servidor real, seu endereço IP, barras à direita na URL, etc. Eu sempre tenho esse erro.

Eu usei O Google para pesquisá-lo. Muitas pessoas enfrentam esse problema, ou variações do mesmo, Mas ninguém parecia ter resolvido.

MOSS matreiro fornecido um detalhado erro que não ocorreu-me para verificar o 12 logs de colméia. Eventualmente, sobre 24 horas depois meu colega recomendado que fazê-lo, Eu verifiquei o 12 colmeia log e encontrei isto:

Ocorreu uma exceção ao tentar adquirir o farm local:
System.Security.SecurityException: Acesso ao registro solicitado não é permitido.
em System.ThrowHelper.ThrowSecurityException(ExceptionResource resource) em Microsoft.Win32.RegistryKey.OpenSubKey(Nome de cadeia de caracteres, Boolean writable) em Microsoft.Win32.RegistryKey.OpenSubKey(Nome de cadeia de caracteres) em Microsoft.SharePoint.Administration.SPConfigurationDatabase.get_RegistryConnectionString() em Microsoft.SharePoint.Administration.SPConfigurationDatabase.get_Local() em Microsoft.SharePoint.Administration.SPFarm.FindLocal(SPFarm& fazenda, Boolean& isJoined)
A zona do assembly que falhou foi:  Meu computador

Isso abriu novos caminhos de pesquisa, Então foi para o Google. Isso me levou a isto post no fórum: http://forums.CodeCharge.com/posts.php?post_id = 67135. Isso realmente não me ajudou... mas fez começar fazendo-me pensar que havia um problema de banco de dados e/ou segurança. Eu batalharam e De Andrew Connell postar finalmente despoletado o pensamento que eu deve certificar-se de que a conta de identidade do pool de aplicativos tinha acesso adequado ao banco de dados. Eu pensei que ele já fez.. No entanto, minha colega foi e deu o app pool identidade conta completo para SQL.

Assim que ela fez essa mudança, Tudo começou a trabalhar.

Aconteceu o que se segue é melhor expressa como uma haicai poema:

Problemas levantam as mãos.
Você balança e falhar. Tentar novamente.
Sucesso! Mas como? Por que?

Ela não queria deixar as coisas em paz assim, preferindo dar a permissão mínima necessária (e provavelmente com um olho para gravar uma entrada de blog; Eu batia o soco, muhahahahaha!).

Ela afastada sucessivas permissões da conta de identidade do pool de aplicativo até … Já não havia qualquer permissão explícita para a conta de identidade do pool de aplicativo em todos os. O serviço da web continuou a funcionar muito bem.

Fomos e reiniciei as servidores. Tudo continuou a funcionar bem.

Assim, para recapitular: Demos o app pool identidade completo e em seguida levou embora. O serviço da web começou a trabalhar e nunca parou de funcionar. Bizarro.

Se alguém sabe por que isso deveria ter funcionado., por favor, deixe um comentário.

</fim>

Eu precisava atender a um requisito de segurança para um formulário do InfoPath hoje. Nesta situação de negócios, um número relativamente pequeno de indivíduos têm permissão para criar um novo formulário do InfoPath e uma audiência muito mais ampla são permitidos para editá-lo. (Esta é a nova contratação ambientação formulário usado pelos recursos humanos que inicia um fluxo de trabalho).

Para cumprir esse objectivo, Criei criado dois novos níveis de permissão ("criar e atualizar" e "atualizar apenas"), quebrou a herança para a biblioteca de formulários e permissões para a "criar, atualização" usuário e uma "atualização separada apenas" usuário. A mecânica todo trabalhada, Mas isso acabou por ser um pouco mais envolvendo do que eu esperava. (Se você se sentir um pouco instável nas permissões do SharePoint, Confira este post de blog). A configuração de segurança necessárias para o nível de permissão não era óbvio conjunto de permissões granulares. Para criar um nível de permissão somente atualização para um formulário do InfoPath, I did the following:

1. Criar um novo nível de permissão.
2. Limpar todas as opções.
3. Selecionado o seguinte a partir de "Lista de permissões":

• Editar itens
• Ver itens
• Exibir páginas de aplicativo

A seleção dessas opções permite que o usuário atualizar um formulário, mas não criá-lo.

O truque era permitir que as páginas de aplicativo"vista". Lá não é nenhuma verbage sobre o nível de permissão que indica que é necessário para atualizar somente os formulários do InfoPath, mas gira para fora é.

Criar-e-Update foi ainda mais estranho. Segui os mesmos passos, 1 por meio de 3 acima. Eu tive que adicionar especificamente uma permissão do Site"" opção: "Usar recursos de integração do cliente". Mais uma vez, a descrição não faz parecer que deveria ser obrigatório para um formulário do InfoPath, mas ele está lá.

</fim>

ATUALIZAÇÃO 01/28/08: Este projeto codeplex resolve esse problema: http://www.codeplex.com/AccessChecker. Eu não usei isso, Mas parece promissor, se esta é uma questão que você precisa para o endereço em seu ambiente.

ATUALIZAÇÃO 11/13/08: Joel Oleson escreveu um post muito bom sobre o maior problema de gestão segurança aqui: http://www.sharepointjoel.com/ Lists/Posts/Post.aspx?Lista = 0cd1a63d % 2D183c % 2D4fc2 %2 D 8320% 2Dba5369008acb&ID = 113. Links para uma série de outros recursos úteis.

Clientes e usuários do fórum, muitas vezes, fazer uma pergunta ao longo destas linhas: "Como gerar uma lista de todos os usuários com acesso a um site" ou "como posso eu automaticamente alertar todos os usuários com acesso à lista sobre as alterações feitas à lista?"

Não há nenhuma solução out of the box para isso. Se você pensar sobre isso por um momento, Não é difícil entender por que.

Segurança do SharePoint é muito flexível. Existem pelo menos quatro grandes categorias de usuários:

• Usuários anônimos.
• Grupos e usuários do SharePoint.
• Usuários do Active Directory.
• Autenticação baseado em formulários (FBA) usuários.

A flexibilidade significa que a partir de uma perspectiva de segurança, qualquer determinado site SharePoint será drasticamente diferente do outro. A fim de gerar um relatório de lista de acesso, é preciso verificar como o site é seguro, consultar múltiplos repositórios de perfil de usuário diferente e em seguida, apresentá-lo de forma útil. Isso é um problema difícil de resolver, genericamente.

Como organizações estão lidando com isto? Eu gostaria de ouvir de você em comentários ou Email.

</fim>

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!