Artigo
09/28/2010

Protegendo 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.

Access baseado em funções 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 dos casos, você provavelmente vai usar as permissões que são herdadas de uma pasta pai. A definição de segurança em relatórios e recursos individuais é necessária somente se você desejar ocultar o relatório ou recurso dos usuários que não precisam saber de sua existência ou desejar 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 grupo menor de usuários e fornecer a todos ou a alguns deles privilégios adicionais para gerenciar o relatório.

Você talvez precise 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 ao qual somente poucas pessoas têm acesso, o relatório continuará disponível somente para esses usuários mesmo que seja movido para uma pasta que tem uma diretiva de segurança relativamente aberta.

Diminuindo ataques de injeção 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 contém 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 recursos processados como HTML, é importante lembrar que os relatórios são processados em confiança total e que scripts possivelmente suspeitos podem ser enviados 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 conteúdos suspeitos podem ser publicados, limite 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.

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

Em qualquer relatório que inclua um parâmetro do tipo String, use uma lista de valores disponíveis (também conhecida como uma lista de valores válidos) e verifique se todos os usuários que executam o relatório têm somente as permissões necessárias para exibir os dados do relatório. Ao definir um parâmetro do tipo String, é exibida para o usuário uma caixa de texto que pode ter qualquer valor. Uma lista de valores disponíveis limita os valores que podem ser inseridos. Se o parâmetro de relatório estiver associado a um parâmetro de consulta e uma lista de valores disponíveis não for usada, um usuário do relatório poderá digitar a sintaxe SQL na caixa de texto, abrindo possivelmente o relatório e seu servidor a um ataque de injeção SQL. Se o usuário tiver permissões suficientes para executar a nova instrução SQL, resultados indesejados podem ser produzidos no servidor.

Se um parâmetro de relatório não estiver associado a um parâmetro de consulta e os valores de parâmetro forem incluídos no relatório, um usuário do relatório poderá digitar a sintaxe de expressão ou um URL no valor de parâmetro e processar o relatório em Excel ou HTML. Se outro usuário exibir o relatório e clicar no conteúdo do parâmetro processado, o usuário poderá executar acidentalmente o script ou link mal-intencionado.

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

Observação
Em versões anteriores da documentação, foi incluído um exemplo de criação de uma consulta dinâmica como uma expressão. Esse tipo de consulta cria uma vulnerabilidade a ataques de injeção SQL e, portanto, não é recomendado.

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 Especificando informações de credencial e conexão para fontes de dados do relatório. Você também pode proteger uma pasta deixá-la inacessível para usuários sem autorização. Para obter mais informações, consulte Protegendo pastas.