Artigo
10/19/2015

Este artigo foi traduzido por máquina.

Segurança do SharePoint

Filtre os resultados de pesquisa do SharePoint para aumentar a segurança

Carlos Elenjickal

A pesquisa do Microsoft SharePoint usa uma conta que normalmente tem acesso de leitura completo entre o repositório para indexar seu conteúdo. Portanto, é importante que, quando um usuário as consultas para algum conteúdo, ele deve ser restrito para exibir apenas os documentos, ele tem permissão para ver. O SharePoint usa a lista de controle de acesso (ACL) associada a cada documento para aparar a que os usuários não tem permissão para exibir resultados da consulta, mas a restrição de padrão fornecida pelo SharePoint (aparamento de out-of-box) pode não ser adequada para atender às necessidades de segurança de dados. Nesse caso, talvez queira cortar ainda mais os resultados dependendo da estrutura de autenticação de uma organização.

Isso é onde a infra-estrutura de aparamento de segurança personalizada SharePoint é útil. SharePoint permite implementar a lógica de negócios em um módulo separado e integrá-lo o fluxo de trabalho com o processador de consultas que serve de consultas. O caminho de aparamento de segurança, a remoção de consulta personalizada segue o aparamento de segurança de out-of-box. Portanto, o número de resultados de consulta após remoção personalizada deve ser igual ou menor que o número de documentos recuperados antes de registrar o assembly de limpa (CST) de segurança personalizado.

Antes de investigar na arquitetura do CST, forneceremos uma visão rápida de pesquisa do SharePoint e a nova infra-estrutura de autenticação de declarações.

Visão geral da pesquisa do SharePoint

Em um alto nível, o sistema de pesquisa pode ser dividido em duas partes distintas: o canal de coletor e o pipeline de processador de consulta.

Pipeline do gathererEssa parte é responsável pelo rastreamento e indexação de conteúdo de vários repositórios, como sites do SharePoint, sites HTTP, arquivo compartilhamentos, Lotus Notes, Exchange Server e assim por diante. Esse componente reside dentro MSSearch.exe. Quando é emitida uma solicitação para rastrear um repositório, o coletor invoca um daemon de filtro MssDmn.exe, para carregar os manipuladores de protocolo necessário e os filtros necessários para se conectar, recuperar e analisar o conteúdo. A Figura 1 representa uma exibição simplificada do pipeline do gatherer.

image: A Simplifed View of the SharePoint Gatherer Pipeline

Figura 1 um modo de exibição simplificado do pipeline de coletor do SharePoint

SharePoint pode rastrear somente usando uma conta de autenticação NTLM do Windows. Fonte de conteúdo deve autorizar a conta do Windows enviada como parte da solicitação de rastreamento para acessar o conteúdo do documento. Embora as declarações autenticação é suportada no SharePoint 2010, o coletor não ainda é um aplicativo compatível com declarações e não irá acessar uma fonte de conteúdo que tenha somente a autenticação de declarações.

Pipeline de processador de consultaNo SharePoint 2010, dois dos mais importantes alterações no pipeline de processador de consulta estão na sua topológica de escalabilidade e o modelo de autenticação. No Microsoft SharePoint Server (MOSS) 2007, o processador de consultas (local e de consulta as configurações de serviço de pesquisa, conhecido como serviço de consulta de pesquisa a partir daqui em) é executado no mesmo processo do Web front-end (WFE), mas em SharePoint 2010 pode executado em qualquer lugar no farm — e também é executado como um serviço da Web.

O WFE comunica-se com o serviço de consulta de pesquisa por meio de chamadas do Windows Communication Foundation (WCF). O serviço de consulta de pesquisa é agora totalmente construído sobre a infra-estrutura de autenticação de declarações de SharePoint. Isso dissocia pesquisa do SharePoint a partir de sua total integração com a autenticação do Windows e autenticação de formulários. Como resultado, o SharePoint agora oferece suporte vários modelos de autenticação. O serviço de consulta de pesquisa apara os resultados da pesquisa de acordo com os direitos do usuário que emite a consulta. Trimmers de segurança personalizadas são chamados pelo serviço de pesquisa de consulta após a remoção de out-of-box. Quando uma consulta é executada, consulte o do Figura 2 para os vários componentes envolvidos.

image: Workflow of a Query Originating from the Search Center in a SharePoint Site

Do fluxo de trabalho de uma consulta de origem a partir do Centro de pesquisa no site do SharePoint, a Figura 2

O aparamento de segurança personalizado é parte do canal de consulta, portanto, o irá limitar essa discussão para componentes do pipeline de consulta.

Autenticação de declarações no SharePoint 2010

Uma compreensão básica do suporte à autenticação de declarações em SharePoint 2010 é necessária para implementar a lógica de remoção personalizada dentro de um assembly CST. No ambiente de solicitações autenticadas, a identidade do usuário é mantida dentro de um envelope chamado um token de segurança. Ele contém uma coleção de declarações de identidade ou declarações sobre o usuário. São exemplos de declarações de nome de usuário, endereço de email, número de telefone, função e assim por diante. Cada declaração terá vários atributos, como o tipo de e de valor de . Por exemplo, em uma declaração de UserLogonName pode ser o tipo de e o nome do usuário conectado momento pode ser o valor de .

Tokens de segurança são emitidos por uma entidade chamada a um serviço de token de segurança (STS). Este é um serviço da Web que responde às solicitações de autenticação de usuário. Quando o usuário é autenticado, STS envia de volta um token de segurança com os direitos de usuário. STS podem ser configurados para residir no mesmo farm do SharePoint ou atuar como uma parte confiante para o STS de outro que reside outsides do farm: Provedor de identidade-STS (IP-STS) e dependente festa-STS (RP-STS), respectivamente. Se você deseja usar o IP-STS RP-STS deve ser cuidadosamente consideradas durante a criação de implantação do SharePoint.

O SharePoint usa o provedor de declarações padrão fornecido com o produto em uma instalação simples. Mesmo se você configurar o farm completamente usando a autenticação do Windows, quando uma consulta é emitida, um proxy de aplicativo do serviço de pesquisa falará ao STS para extrair todos os pedidos do usuário em segurança de um token. Esse token é então passado para o serviço de consulta de pesquisa por meio de uma chamada WCF.

Fluxo de trabalho de aparamento de segurança personalizado

A lógica do fluxo de trabalho de um CST pode ser representada em um fluxograma simples, como mostrado no do Figura 3.

image: The Workflow Logic of a CST

A Figura 3 da lógica de fluxo de trabalho de um CST

Conforme mencionado anteriormente, o serviço de pesquisa de consulta executa pela primeira vez o aparamento de segurança fora da caixa e, em seguida, procura a presença de qualquer CSTs associados com os resultados da pesquisa. A associação de uma fonte de conteúdo específica a um CST é feita definindo-se uma regra de rastreamento de para essa fonte de conteúdo específico. Se o serviço de consulta de pesquisa localiza qualquer CST associado a qualquer um dos URLs nos resultados da pesquisa, ele chama esse limpa. Trimmers são carregados para o mesmo processo do operador IIS, W3wp. exe, no qual o serviço de consulta de pesquisa está sendo executado.

Depois que o limpa é carregada, o serviço de consulta de pesquisa chama o método CheckAccess implementado dentro da limpa com um conjunto de resultados aparamento de out-of-box associado à regra de rastreamento que você definiu anteriormente. O método CheckAccess decide se uma URL específica deve ser incluída no conjunto do resultado final enviado de volta para o usuário. Isso é feito por meio do retorno de uma matriz de bits. Configuração um pouco dentro dessa matriz como verdadeira ou falsa “ incluem ” ou a URL a partir do resultado final “ bloco ” definirá. Caso você deseje parar de processar as URLs devido ao desempenho ou alguma razão inesperado, você deve lançar uma PluggableAccessCheckException. Se você lançar após o processamento de uma lista parcial das URLs, os resultados processados são enviados para o usuário. O serviço de consulta de pesquisa removerá todas as URLs não processadas do conjunto de resultados finais.

Passos envolvidos na implantação de uma unidade de corte de segurança personalizado

Neste mundo insano, há cinco etapas envolvidas na implantação bem-sucedida de um CST:

Implemente interface ISecurityTrimmer2.
1. Implementar métodos de inicialização e CheckAccess usando código gerenciado
2. Criar um arquivo de assinatura de assembly e incluí-la como parte do projeto
3. Compilar o assembly
Implante a limpa no GAC (cache de Assembly Global) de todas as máquinas em que um serviço de consulta de pesquisa está sendo executado.
Crie uma regra de rastreamento para as fontes de conteúdo que você deseja apara personalizada. Você pode fazer isso partir do site de administração de pesquisa.
Registre a limpa a regra de rastreamento usando o Windows PowerShell cmdlet do Novo SPEnterpriseSearchSecurityTrimmer.
Execute um rastreamento completo , as fontes de conteúdo associados com as regras de rastreamento que você criou na etapa 3. Um rastreamento completo é necessário para atualizar adequadamente todas as tabelas de banco de dados relacionados. Um rastreamento incremental não atualizará as tabelas apropriadas.

Implementando a interface do corte de segurança personalizado

O MOSS 2007 e o servidor de pesquisa da Microsoft (MSS) 2008, suporte para o aparamento de segurança personalizado de resultados da pesquisa através da interface o ISecurityTrimmer. Essa interface possui dois métodos Initialize e CheckAccess. Devido às alterações de arquitetura do SharePoint e o sistema de pesquisa nas versões 2010, ambos os métodos não funcionam da mesma forma que no MOSS 2007. Eles precisam ser reimplementadas usando a interface ISecurityTrimmer2. Como resultado, se você tentar registrar uma limpa o MOSS 2007 no SharePoint 2010, ele falhará, informando que ISecurityTrimmer2 não está implementado. Outras alterações do MOSS 2007 incluem:

Alterações no método de inicializaçãoNo MOSS 2007, um dos parâmetros passados era o objeto SearchContext ser. SearchContext ser foi o ponto de entrada para o sistema de pesquisa e ele fornecido o contexto de pesquisa para o provedor de serviços de site ou de pesquisa (SSP). Essa classe foi substituída em 2010. Em vez disso, use a classe SearchServiceApplication:

void Initialize(NameValueCollection staticProperties, SearchServiceApplication searchApplication);

Alterações no método de CheckAccessNo MOSS 2007 e no SharePoint 2010, o serviço de consulta de pesquisa chama os assemblies do CST. No MOSS 2007, o método CheckAccess levou apenas dois parâmetros, mas em SharePoint 2010, o serviço de consulta de pesquisa passa a identidade do usuário em CheckAccess usando um terceiro parâmetro do tipo IIdentity:

public BitArray CheckAccess(IList<String>documentCrawlUrls, IDictionary<String, Object>sessionProperties, IIdentity passedUserIdentity)

Método ISecurityTrimmer2::InitializeEsse método é chamado na primeira vez que uma limpa é carregada no processo do operador do IIS de serviço de pesquisa consulta. O assembly será vivem pela duração do processo do operador. Esta é a assinatura desse método e uma descrição de como funciona:

void Initialize(NameValueCollection staticProperties, SearchServiceApplication searchApplication);

staticProperties –The corte registro do Windows PowerShell cmdlet, New-SPEnterpriseSearchSecurityTrimmer, leva um parâmetro chamado “ propriedades ” (no MOSS 2007 foi chamado “ configprops ”) através do qual você pode passar nomeado pares de valor separado por ~. Isso pode ser útil para inicializar as propriedades de classe de corte.

Por exemplo: Ao passar “ superadmin ~ foouser ~ poweruser ~ baruser ” para o cmdlet New-SPEnterpriseSearchSecurityTrimmer, o parâmetro NameValueCollection terá dois itens na coleção com chaves como “ superadmin ” e ” poweruser ” e valores como “ foouser ” e “ baruser ”, respectivamente.

searchApplication – De se seu limpa requer um conhecimento mais profundo sobre a instância do serviço de pesquisa e o farm do SharePoint, use um objeto searchApplication para determinar as informações. Para obter mais informações sobre a classe SearchServiceApplication, consulte msdn.microsoft.com/library/ee573121(v=office.14) de .

Método ISecurityTrimmer2::CheckAccessImplementa a toda a lógica de corte. Nesse método de pagamento especial atenção aos dois aspectos: a identidade do usuário que emitiu a consulta e a latência de desempenho causados por um conjunto grande de consulta retornado.

Veja a seguir a assinatura desse método e uma descrição de como funciona:

public BitArray CheckAccess(IList<String>documentCrawlUrls, IDictionary<String, Object>sessionProperties, IIdentitypassedUserIdentity)

documentCrawlUrlsColeção de –The das URLs seja cortada por esse limpa de segurança.

sessionPropertiesInstância de consulta simples –A é tratada como uma sessão. Se sua consulta busca muitos resultados, o método CheckAccess é chamado várias vezes. Você pode usar esse parâmetro para compartilhar valores ou para manter o controle das URLs processados entre essas chamadas.

passedUserIdentity –This é a identidade do usuário que emitiu a consulta. É a identidade por meio do qual o código irá permitir ou negar acesso ao conteúdo.

BitArray –You precise retornar uma matriz de bits igual ao número de itens em documentCrawlUrls. Configuração um pouco dentro desta matriz como true ou false determinará o URL nessa posição deve ser incluído ou bloqueado para o conjunto do resultado final enviado de volta para o usuário.

UserIdentityO mecanismo de consulta de pesquisa do SharePoint 2010 baseia-se se o modelo de autenticação de declarações. O serviço de consulta de pesquisa irá passar solicitações de consulta do emissor Embora o parâmetro IIdentity. Para obter o nome de usuário do usuário que emitiu a consulta, você deve percorrer através de uma coleção de declarações para comparar o claim.ClaimType com o SPClaimTypes.UserLogonName.

O trecho de código a seguir extrai o nome de logon do usuário do token de declarações:

IClaimsIdentity claimsIdentity = (IClaimsIdentity)passedUserIdentity;

if (null != claimsIdentity)
{
  foreach (Claim claim in claimsIdentity.Claims)
  {
    if (claim == null)
      continue;
    if (SPClaimTypes.Equals(claim.ClaimType, SPClaimTypes.UserLogonName))
      strUser = claim.Value;
  }
}

Você pode precisar de informações sobre o tipo de autenticação usado no nível do conjunto de sites corretamente chamar as APIs internas. Para identificar se o usuário tiver feito logon usando autenticação do Windows, procure a presença de do ClaimsType.PrimarySid. O código a seguir procura a alegação de PrimarySid e, em seguida, extrai o nome de usuário dela:

if (SPClaimTypes.Equals(claim.ClaimType, ClaimTypes.PrimarySid))
{
  // Extract SID in the format "S-1-5-21-xxxxx-xxxxx-xxx"
  strUser = claim.Value;
  // Convert SID into NT Format "FooDomain\BarUser"
  SecurityIdentifier sid = new SecurityIdentifier(strUser);
  strUser = sid.Translate(typeof(NTAccount)).Value;
}

Para formulários ou outros provedores de autenticação semelhante de não-Windows, veja o valor de Claim.OriginalIssuer dentro da declaração . Por exemplo, se o servidor está configurado para autenticação de formulários usando o provedor de associação do SQL do asp.net, o Claim.OriginalIssuer terá o valor "Forms: AspNetSqlMembershipProvider":

if (SPClaimTypes.Equals(claim.ClaimType, SPClaimTypes.UserLogonName))
{
  strUser = claim.Value;
  strProvider = claim.OriginalIssuer; // For AspNet SQL Provider value will be
                                      // "Forms:AspNetSqlMembershipProvider"
}

Se a consulta é emitida por um usuário anônimo, o valor do método IIdentity.IsAuthenticated será false. Nesse caso, claimsIdentity.Name terá o valor "NT AUTHORITY\\ANONYMOUS LOGON".

Como uma observação final sobre o contexto de usuário, limite o uso de .Name de () API WindowsIdentity.GetCurrent para recuperar a identidade do usuário. Isso dará sempre a identidade do pool de aplicativos sob a qual o serviço de consulta de pesquisa está sendo executado. System.Threading.Thread.CurrentPrincipal.Identity, você terá a mesma identidade como o que é passado para o método CheckAccess.

Considerações sobre desempenhoOtimize o método CheckAccess até o tamanho máximo. Se a consulta retorna muito resultados, a limpa pode ser chamada várias vezes. Um dos métodos comuns para cuidar dessa situação é manter o controle das URLs processadas dentro da limpa através do parâmetro sessionProperties. Depois que o método processa um certo número de conjuntos de resultados, ele pode gerar um PluggableAccessCheckException. Quando essa exceção é lançada, as URLs processadas até que ponto são retornadas ao usuário.

Unidade de corte de segurança personalizado e os logs do sistema

Não é possível gravar código dentro de um limpa os logs do sistema mantidos em <drive> \ Program Files\Common Files\Microsoft Shared\Web Server Extensions\14\LOGS. A limpa deve manter seu próprio mecanismo de log de depuração e a auditoria. A única exceção é quando o método lança o PluggableAccessCheckException. A seqüência de caracteres de mensagem especificada durante o lançamento será registrada no log do sistema. Informações úteis que o serviço de pesquisa de consulta registra o arquivo incluem o número de documentos que foram cortada de segurança. Por exemplo, a seguinte entrada do log sugere que uma consulta passada dois documentos para o CST mas enviado zero documentos para o usuário, o que significa que o CST aparada nesses dois documentos:

04/23/2010 18:13:48.67    w3wp.exe (0x116C)    0x02B4    SharePoint Server Search    Query Processor    dm2e    Medium    Trim results: First result position = '0', actual result count = '0', total docs found = '0', total docs scanned = '2'.    742d0c36-ea37-4eee-bf8c-f2c662bc6a45

Trimmers de segurança personalizado e alertas O serviço de pesquisa do SharePoint possui um recurso chamado alertas (available only in Windows authentication mode) que pode enviar as alterações nos resultados da consulta ao usuário através de emails.No entanto, quando uma consulta de alerta será emitida pelo serviço de timer, o serviço de consulta de pesquisa irá retirar todas as URLs associadas CSTs.

Requisitos de assinatura de assemblyComo localizar a presença de um CST correspondente, o serviço de consulta de pesquisa chama o código de gerenciamento de CST para carregar o assembly específico do GAC.Para fazer isso, o assembly precisa ser assinado digitalmente.Consulte “ Gerenciando e manifesto de assinatura de assembly ” (msdn.microsoft.com/library/ms247066 ) para obter formas de assinar um assembly.Depois que o assembly é compilado, use a ferramenta sn.exe para obter o hash de 64 bits, conhecido como um token de chave pública.Esse token é necessária no momento do registro de corte.

Implantação da unidade de corte de segurança personalizadoO  assembly CST deve residir no GAC de cada computador em que o serviço de configurações de site e de consulta de pesquisa está sendo executado.Use a administração central | configurações do sistema | serviços no servidor para verificar o status do serviço de pesquisa local e de consulta as configurações em cada uma das máquinas do farm.Se o serviço for iniciado, você deve importar do CST para aquela máquina.Don confunda o serviço de configurações de site e consulta de pesquisa com os computadores que contêm componentes de consulta.O componente de consulta reside no MSSearch.exe para receber os resultados do índice.O serviço de configurações de site e de consulta de pesquisa reside em seu próprio processo de trabalho do IIS de w3wp. exe.

Cmdlets do SharePoint para registrar, exibir e excluir CSTs

O MOSS 2007 usado a ferramenta de linha de comando Stsadm. exe para registrar trimmers personalizados, mas essa ferramenta é obsoleto e não suportados em SharePoint 2010.Em vez disso, use os cmdlets do Windows PowerShell para registrar, exibir e excluir CSTs.Um assembly já deve estar disponível no GAC para registrá-los.Eis como utilizá-los:

Registro –Use o SPEnterpriseSearchSecurityTrimmer de novo para registrar seu limpa, usando os dados de manifesto do assembly, como versão, cultura e PublicKeyToken.Este exemplo registra a limpa para o aplicativo de pesquisa chamado “ aplicativo de serviço de pesquisa ”:

New-SPEnterpriseSearchSecurityTrimmer -SearchApplication "Search Service Application" -TypeName "SearchCustomSecurityTrimmer.CustomSecurityTrimmerTest, SearchCustomSecurityTrimmer, Version=14.0.0.0, Culture=neutral, PublicKeyToken=4ba2b4aceeb50e6d" -RulePath file://elenjickal2/* -id 102 -Properties superadmin~foouser~poweruser~baruser

O cmdlet leva a regra de rastreamento (CaminhoDaRegra), um valor inteiro, como a identidade (id) de propriedades de configuração do corte, (Propriedades) e TypeName, que consiste os manifesto de dados, bem como o nome da classe que implementa a interface. Os parâmetros de cmdlets são:

SearchApplication–Name do aplicativo de serviço de pesquisa associado a fonte de conteúdo
TypeName–This é composto de dados, como versão, cultura e PublicKeyToken manifesto (ele também aponta para a classe que implementa a interface; isso permitirá identificar com exclusividade o assembly do GAC)
Regra de rastreamento RulePath–The associada a limpa
Tipo de dados do int Id–An identifica com exclusividade a instância do corte
Properties–Set dos pares nome/valor separados por ~

Modo de exibição Cmdlet de Get-SPEnterpriseSearchSecurityTrimmer de –Use e passar o nome do aplicativo de pesquisa. Você pode filtrá-lo ainda mais, passando a identidade de corte ou outras propriedades que você usou ao registrar (por exemplo: Obtenha - SPEnterpriseSearchSecurityTrimmer - SearchApplication "Aplicativo do serviço de pesquisa").

Excluir –Use remove-SPEnterpriseSearchSecurityTrimmer cmdlet e passar o aplicativo de pesquisa de nome, bem como a identidade da limpa (por exemplo: Remove-SPEnterpriseSearchSecurityTrimmer - SearchApplication "Aplicativo do serviço de pesquisa" –id 102).

Observação: Após registrar o CST, um rastreamento completo da fonte de conteúdo é necessário.

As etapas de solução de problemas

Aqui estão algumas dicas para investigar os resultados da pesquisa inesperado:

Certifique-se a regra de rastreamento coincide com o local da fonte de conteúdo.
Verifique os logs de rastreamento para certificar-se de que a conta usada para rastrear a fonte de conteúdo tem acesso a ele. O rastreamento teria falhado se isso não acontecer.
Certifique-se que a usuário de consulta tem permissão para exibir o conteúdo.
Depois do corte de registro, verifique se que você executou um rastreamento completo.
Verifique se que o assembly de corte está no GAC de todas as máquinas em que está executando o serviço de consulta de pesquisa.
Verifique os logs de sistema para o número de documentos cortada por limpa a segurança.
Use o utilitário ProcessExplorer a partir de technet.microsoft.com/sysinternals/bb896653 para certificar-se de que o assembly do corte é carregado no processo de operador IIS W3wp. exe.
Anexe o depurador ao processo do operador no qual o conjunto é carregado e percorra a lógica de corte.

Flexibilidade de lógica de processamento de consulta

Quebra automática de, CSTs fornecem a flexibilidade para estender a lógica para atender às necessidades de segurança da empresa personalizados de processamento de consultas. Uma sempre deve ter em mente que os bugs de implementação dentro da limpa podem causar resultados inesperados, portanto, é importante que antes da limpa for implantada em um ambiente de produção, ele é totalmente testado em relação a diferentes tipos de fontes de conteúdo e provedores de autenticação.

Carlos Elenjickal e Pooja Harjani parte de uma equipe de recurso de pesquisa do SharePoint foram responsáveis por Custom Security Trimmer na Microsoft. Eles podem ser contatados pelo AshleyEl@microsoft.com e do PVaswani@microsoft.com, respectivamente.

Meus agradecimentos aos seguinte especialista técnico para revisar este artigo: Michal Piaseczny