Proteger relatórios e recursos

É possível definir a segurança de relatórios e recursos individuais para controlar o nível de acesso que os usuários têm a esses itens. Por padrão, somente os usuários que são membros do grupo interno de Administradores podem executar relatórios, exibir recursos, modificar propriedades e excluir os itens. Todos os outros usuários devem ter atribuições de função que permitam o acesso a um relatório ou recurso.

Acesso baseado em função a relatórios e recursos

Para conceder acesso a relatórios e recursos, você pode permitir que os usuários herdem as atribuições de função existentes de uma pasta pai ou criem uma nova atribuição de função no próprio item.

Na maioria das vezes, você provavelmente desejará usar as permissões herdadas de uma pasta pai. A configuração da segurança em relatórios e recursos individuais só deve ser necessária se você quiser ocultar o relatório ou o recurso de usuários que não precisam saber se o relatório ou recurso existe ou aumentar o nível de acesso para um relatório ou item. Esses objetivos não são mutuamente exclusivos. Você pode restringir o acesso a um relatório a um conjunto menor de usuários e fornecer a todos ou a alguns deles privilégios adicionais para gerenciar o relatório.

Talvez seja necessário criar várias atribuições de função para alcançar seus objetivos. Por exemplo, suponha que você queira disponibilizar um relatório para dois usuários Ann e Fernando, e para o grupo Gerentes de Recursos Humanos. Ann e Fernando devem poder gerenciar o relatório, mas os membros do grupo só precisam executá-lo. Para acomodar todos esses usuários, você deveria criar três atribuição de função separadas: uma para que Ann fosse gerente de conteúdo do relatório, uma para Fernando ser gerente de conteúdo do relatório e outra para dar suporte a tarefas de somente exibição para o grupo Gerentes de Recursos Humanos.

Depois de definir a segurança em um relatório ou recurso, essas configurações permanecem com o item, mesmo que ele seja movido para um novo local. Por exemplo, se você mover um relatório que apenas algumas pessoas estão autorizadas a acessar, o relatório continuará disponível apenas para esses usuários, mesmo que você o mova para uma pasta que tenha uma política de segurança relativamente aberta.

Mitigando ataques de injeção de HTML em um relatório ou documento publicado

No Reporting Services, relatórios e recursos são processados com a identidade de segurança do usuário que está executando o relatório. Se o relatório contiver expressões, scripts, itens de relatório personalizados ou assemblies personalizados, o código será executado com as credenciais do usuário. Se um recurso for um documento HTML que contenha script, o script será executado quando o usuário abrir o documento no servidor de relatório. A possibilidade de executar scripts ou códigos em um relatório é um recurso avançado que pode ser um pouco arriscado. Se o código for suspeito, o servidor de relatório e o usuário que está executando o relatório estarão vulneráveis a ataques.

Ao conceder acesso a relatórios e a recursos processados como HTML, é importante lembrar que os relatórios são processados com total confiança e que o script potencialmente mal-intencionado pode ser enviado ao cliente. Dependendo das configurações do navegador, o cliente executará o HTML no nível de confiança especificado no navegador.

Você pode diminuir o risco de executar scripts suspeitos tomando as seguintes precauções:

• Tome cuidado ao decidir quem pode publicar conteúdo em um servidor de relatório. Como existe o potencial de publicação de conteúdo mal-intencionado, você deve limitar os usuários que podem publicar conteúdo a um pequeno número de usuários confiáveis.

• Todos os editores devem evitar publicar relatórios e recursos provenientes de origens desconhecidas ou não confiáveis. Se necessário, abra o arquivo em um editor de textos e procure scripts e URLs suspeitos.

Parâmetros de relatório e injeção de script

Os Parâmetros de Relatório proporcionam flexibilidade para o projeto geral e a emissão do relatório. Porém, essa mesma flexibilidade pode, em alguns casos, ser usada por um invasor em ataques de atração. Para atenuar o risco de execução acidental de scripts mal-intencionados, abra apenas relatórios renderizados de fontes confiáveis. É recomendável que você considere o seguinte cenário que é um possível ataque de injeção de script do Renderizador HTML:

1. Um relatório contém uma caixa de texto com a ação de hiperlink definida como o valor de um parâmetro que pode conter texto mal-intencionado.

2. O relatório é publicado em um servidor de relatórios ou de outra forma disponibilizado de modo que o valor de parâmetro de relatório possa ser controlado pela URL de uma página da Web.

3. Um invasor cria um link para a página da web ou servidor de relatórios especificando o valor do parâmetro no formato "javascript:<script mal-intencionado aqui>" e envia esse link para outra pessoa em um ataque de phishing.

Mitigando ataques de injeção de script em um hiperlink em um relatório ou documento publicado

Relatórios podem conter hiperlinks inseridos no valor da propriedade Action de um item de relatório ou parte de um item de relatório. Hiperlinks podem ser associados a dados que recuperados de uma fonte de dados externa quando o relatório é processado. Se um usuário mal-intencionado modificar os dados subjacentes, o hiperlink pode correr o risco de explorações de script. Se um usuário clicar no link no relatório publicado ou exportado, o script mal-intencionado poderá ser executado.

Para atenuar o risco de incluir links em um relatório que executam inadvertidamente scripts mal-intencionados, associe hiperlinks a dados apenas de fontes confiáveis. Verifique se os dados dos resultados da consulta e as expressões que associam dados a hiperlinks não criam links que podem ser explorados. Por exemplo, não baseie um hiperlink em uma expressão que concatena dados de vários campos de conjunto de dados. Se necessário, navegue até o relatório e use "Exibir origem" para verificar scripts e URLs suspeitos.

Mitigando ataques de injeção de SQL em um relatório parametrizado

Em qualquer relatório que inclua um parâmetro de tipo String, use uma lista de valores disponíveis (também conhecida como uma lista de valores válidos) e verifique se qualquer usuário que executa o relatório tem apenas as permissões necessárias para exibir os dados no relatório. Quando você define um parâmetro de tipo String, o usuário recebe uma caixa de texto que pode levar qualquer valor. Uma lista de valores disponíveis limita os valores que podem ser inseridos. Se o parâmetro de relatório estiver vinculado a um parâmetro de consulta e você não usar uma lista de valores disponíveis, será possível que um usuário de relatório digite a sintaxe SQL na caixa de texto, potencialmente abrindo o relatório e seu servidor para um ataque de injeção de SQL. Se o usuário tiver permissões suficientes para executar a nova instrução SQL, ele poderá produzir resultados indesejados no servidor.

Se um parâmetro de relatório não estiver vinculado a um parâmetro de consulta e os valores de parâmetro forem incluídos no relatório, será possível que um usuário de relatório digite a sintaxe de expressão ou uma URL no valor do parâmetro e renderize o relatório para Excel ou HTML. Se outro usuário exibir o relatório e clicar no conteúdo do parâmetro renderizado, o usuário poderá executar inadvertidamente o script ou link mal-intencionado.

Para reduzir o risco de execução acidental de scripts mal-intencionados, só abra relatórios renderizados de fontes confiáveis.

Protegendo relatórios confidenciais

Os relatórios que contêm informações confidenciais devem ser protegidos no nível de acesso aos dados, solicitando que os usuários forneçam credenciais para acessar dados confidenciais. Para obter mais informações, consulte Especificar informações de credenciais e de conexão para fontes de dados de relatório. Você também pode proteger uma pasta deixá-la inacessível para usuários não autorizados. Para obter mais informações, consulte Proteger pastas.

Consulte Também

(create-and-manage-role-assignments.md)
Configurar o Acesso ao Construtor de Relatórios
Conceder permissões em um servidor de relatório no Modo Nativo
Itens de fonte de dados compartilhados seguros
Armazenar credenciais em uma fonte de dados do Reporting Services