Compartilhar via


Segurança de acesso ao código no Reporting Services

A segurança de acesso a código se concentra nesses conceitos principais: evidências, grupos de códigos e conjuntos de permissões nomeados. No Reporting Services, os componentes Gerenciador de Relatórios, Designer de Relatórios e Servidor de Relatórios têm cada um um arquivo de política que configura a segurança de acesso de código para assemblies personalizados, bem como dados, entrega, renderização e extensões de segurança. As seções a seguir fornecem uma visão geral da segurança de acesso ao código. Para obter informações mais detalhadas sobre os tópicos abordados nesta seção, consulte "Modelo de Política de Segurança" na documentação do SDK do Microsoft .NET Framework.

O Reporting Services usa a segurança de acesso ao código porque, embora o servidor de relatório seja criado com base na tecnologia ASP.NET, há uma diferença substancial entre um aplicativo ASP.NET típico e o servidor de relatório. Um aplicativo de ASP.NET típico não executa o código do usuário. Por outro lado, o Reporting Services usa uma arquitetura aberta e extensível que permite que os usuários programem em relação aos arquivos de definição de relatório usando o elemento Code da Linguagem de Definição de Relatório e desenvolvam funcionalidades especializadas em um assembly personalizado para uso em relatórios. Além disso, os desenvolvedores podem projetar e implantar extensões avançadas que aprimoram os recursos do servidor de relatório. Com esse poder e flexibilidade vem a necessidade de fornecer o máximo possível de proteção e segurança.

Os desenvolvedores do Reporting Services podem usar qualquer assembly do .NET Framework em seus relatórios e chamar nativamente toda a funcionalidade de assemblies implantados no cache de assembly global. A única coisa que o servidor de relatório pode controlar é quais permissões são dadas para expressões de relatório e assemblies personalizados carregados. No Reporting Services, os assemblies personalizados recebem permissões somente execução por padrão.

Evidência

Evidência são as informações que o CLR (Common Language Runtime) usa para determinar uma política de segurança para assemblies de código. A evidência indica para o runtime que o código tem uma característica específica. As formas comuns de evidência incluem assinaturas digitais e a localização de um assembly. As evidências também podem ser personalizadas projetadas para representar outras informações que sejam significativas para o aplicativo.

Tanto assemblies quanto domínios de aplicativo recebem permissões com base em evidências. Por exemplo, o local de um assembly que o Reporting Services está tentando acessar é uma forma comum de evidência para assemblies com nomes fracos. Isso é conhecido como evidência de URL. A evidência de URL de uma extensão de processamento de dados personalizada implantada em um servidor de relatório pode ser "C:\Program Files\Microsoft SQL Server\MSRS10_50.MSSQLSERVER\Reporting Services\ReportServer\bin\Microsoft.Samples.ReportingServices.FsiDataExtension.dll". O nome forte ou a assinatura digital de um assembly é outra forma comum de evidência. Nesse caso, a evidência é a informação de chave pública para um assembly.

Grupos de códigos

Um grupo de códigos é um agrupamento lógico de código que tem uma condição especificada para associação. Qualquer código que atenda à condição de associação é incluído no grupo. Os administradores configuram uma política de segurança gerenciando grupos de códigos e seus conjuntos de permissões associados.

Uma condição de associação para um grupo de códigos é baseada em evidências. Por exemplo, uma associação de URL para um grupo de códigos é baseada em evidências de URL. O CLR (Common Language Runtime) usa a identificação de características como evidências de URL para descrever o código e determinar se a condição de associação de um grupo foi atendida. Por exemplo, se a condição de associação de um grupo de códigos for "código no assembly C:\Program Files\Microsoft SQL Server\MSRS10_50.MSSQLSERVER\Reporting Services\ReportServer\bin\Microsoft.Samples.ReportingServices.FsiDataExtension.dll", o runtime examinará as evidências para determinar se o código se origina desse local. Um exemplo de uma entrada de configuração para esse tipo de grupo de códigos pode ser semelhante ao seguinte:

<CodeGroup class="UnionCodeGroup"  
   version="1"  
   PermissionSetName="FullTrust"  
   Name="MyCodeGroup"  
   Description="Code group for my data processing extension">  
      <IMembershipCondition class="UrlMembershipCondition"  
         version="1"  
         Url="C:\Program Files\Microsoft SQL Server\MSRS10_50.MSSQLSERVER\Reporting Services\ReportServer\bin\Microsoft.Samples.ReportingServices.FsiDataExtension.dll"  
       />  
</CodeGroup>  

Você deve trabalhar com o administrador do sistema ou especialista em implantação de aplicativos para determinar o tipo de segurança de acesso de código e grupos de código que seus assemblies personalizados ou extensões do Reporting Services exigem.

Conjuntos de permissões nomeados

Um conjunto de permissões nomeado é um conjunto de permissões que os administradores podem associar a um grupo de códigos. A maioria dos conjuntos de permissões nomeados consiste em pelo menos uma permissão, um nome e uma descrição para o conjunto de permissões. Os administradores podem usar conjuntos de permissões nomeados para estabelecer ou modificar a política de segurança para grupos de códigos. Mais de um grupo de códigos pode ser associado ao mesmo conjunto de permissões nomeado. O CLR fornece conjuntos de permissões nomeados internos; entre elas estão Nothing, Execution, Internet, LocalIntranet, Everything e FullTrust.

Observação

Os dados personalizados, a entrega, a renderização e as extensões de segurança no Reporting Services devem ser executados no conjunto de permissões FullTrust . Trabalhe com o administrador do sistema para adicionar o grupo de códigos apropriado e as condições de associação para suas extensões do Reporting Services.

Você pode associar seus próprios níveis personalizados de permissões para assemblies personalizados que você usa com relatórios. Por exemplo, se você quiser permitir que um assembly acesse um arquivo específico, poderá criar um novo conjunto de permissões nomeadas com acesso de E/S de arquivo específico e, em seguida, atribuir o conjunto de permissões ao seu grupo de códigos. O conjunto de permissões a seguir concede acesso somente leitura ao arquivo MyFile.xml:

<PermissionSet class="NamedPermissionSet"  
   version="1"  
   Name="MyNewFilePermissionSet"  
   Description="A special permission set that grants read access to my file.">  
    <IPermission class="FileIOPermission"  
       version="1"  
       Read="C:\MyFile.xml"/>  
    <IPermission class="SecurityPermission"  
       version="1"  
       Flags="Assertion, Execution"/>  
</PermissionSet>  

Um grupo de códigos que você concede a esse conjunto de permissões pode ser semelhante ao seguinte:

<CodeGroup class="UnionCodeGroup"  
   version="1"  
   PermissionSetName="MyNewFilePermissionSet"  
   Name="MyNewCodeGroup"  
   Description="A special code group for my custom assembly.">  
   <IMembershipCondition class="UrlMembershipCondition"  
      version="1"  
      Url="C:\Program Files\Microsoft SQL Server\MSRS10_50.MSSQLSERVER\Reporting Services\ReportServer\bin\MyCustomAssembly.dll"/>  
</CodeGroup>  

Consulte Também

Desenvolvimento Seguro (Reporting Services)