Redução de ameaças e vulnerabilidade (Reporting Services)
Este tópico descreve técnicas e estratégias para reduzir ameaças em uma implantação do Reporting Services.
Visão geral
Um servidor de relatórios é um servidor sem monitoração que armazena conteúdo e dados de aplicativo externamente. Uma das maiores ameaças a uma instalação do servidor de relatórios é o acesso não autorizado ou violação a um banco de dados do servidor de relatórios e arquivos de configuração. Uma ameaça menos óbvia, mas igualmente importante, está relacionada à maneira como você cria relatórios e quem tem permissão para publicar o conteúdo em um servidor de relatórios. As definições de relatório são assemblies que são executados sob confiança total em um computador de servidor. Elas podem conter outros assemblies personalizados que também são executados no servidor. Se o relatório ou um assembly personalizado tiver um código mal-intencionado, esse código será executado no computador do servidor de relatórios com as credenciais do usuário que solicitou o relatório. Outras ameaças sutis podem ser decorrentes de um design de relatório que expõe, sem querer, dados confidenciais. Por exemplo, se um funcionário executa um relatório que usa um ID de funcionário como um parâmetro, esse funcionário não poderá visualizar informações sobre outros funcionários inserindo um ID aleatório em uma URL de relatório. Por fim, considere as práticas de distribuição de relatório em sua organização. Você pode configurar um servidor de relatórios para reduzir a possibilidade de entregar relatórios fora da organização. Também é possível usar permissões tanto no sistema de arquivo quanto no servidor de relatórios para garantir que apenas usuários autorizados possam abrir um relatório.
As seções a seguir neste tópico descrevem ameaças adicionais e indica como reduzir os riscos de uma exploração real.
Reduzindo um ataque em um servidor de relatórios
A tabela a seguir descreve ameaças e atenuações que afetam os componentes de servidor e definições de configuração.
Recurso ou operação |
Ameaça |
Atenuação |
|---|---|---|
As definições de configuração são armazenadas no Web.config e em arquivos de configuração do aplicativo no computador do servidor de relatórios. |
Um invasor pode conseguir acesso ao computador, localizar um arquivo de configuração não criptografado ou desprotegido e violar dados com o arquivo. |
Defina as permissões no arquivo. Por padrão, são concedidas permissões a grupos de segurança do Reporting Services que são criados durante o processo de instalação. |
O serviço Web Servidor de Relatórios processa as solicitações sob demanda enviadas por conexões TCP/IP. |
Um invasor poderia iniciar um ataque de negação de serviço que usa os seguintes formulários: Diversas solicitações não autenticadas são encaminhadas a um servidor de destino. Solicitações incompletas são encaminhadas a um servidor de destino, mas nunca são concluídas. As solicitações são muito extensas; o invasor inicia uma solicitação e envia uma extensa carga útil ao servidor. |
O servidor de relatórios descarta todas as solicitações não autenticadas em dois minutos, o que pode reduzir alguns dos efeitos de um ataque de negação de serviço. O intervalo de dois minutos é fixo; não é possível reduzi-lo. Se o ataque basear-se em operações de transferência para o servidor de relatórios, você pode reduzir o valor do elemento maxRequestLength no arquivo Machine.config. Por padrão, o ASP.NET usa um limite de megabytes (MB) sobre os itens que podem ser transferidos para um aplicativo de servidor. Observe que a redução do valor de maxRequestLength deve ser uma medida temporária. Você pode voltar para o valor anterior caso a transferência de arquivos muito extensos (como modelos) seja uma prática comum. Para obter mais informações sobre como definir maxRequestLength em uma instalação do Reporting Services, consulte Limites de tamanho do relatório e do instantâneo. |
O Reporting Services oferece suporte a uma arquitetura extensível que permite implantar o processamento de dados de terceiros, a renderização e as extensões de entrega. Também é possível implantar designers de consulta personalizados. As extensões devem ser executadas no modo Confiança Total. |
Um invasor pode incluir um código mal-intencionado em uma extensão personalizada. |
Faça a implantação de extensões apenas de usuários ou organizações confiáveis. |
Reduzindo ameaças a Definições de Relatórios e Modelos de Relatório
A tabela a seguir descreve ameaças e atenuações que afetam definições de relatório e arquivos de modelo.
Recurso ou operação |
Ameaça |
Atenuação |
|---|---|---|
Publicando relatórios, modelos e fontes de dados compartilhadas em um servidor de relatórios. Conexão de relatórios e modelos e fontes de dados externas de consulta. |
Interceptando relatórios, modelos e fontes de dados compartilhadas durante uma operação de publicação. Interceptando solicitações que estão em trânsito para um computador externo. |
Usar um canal seguro, criptografado, como SSL/TLS/IPSec, para conexão. As tecnologias de criptografia devem ser usadas para proteger um canal. Informe aos usuários antes de enviar que o canal não é seguro. |
Os tokens de autenticação ou credenciais são usados para estabelecer conexão com computadores e fontes de dados remotos. |
Interceptando dados de autenticação ao processar uma solicitação. |
Use um canal seguro, criptografado. Informe ao usuário se o canal não for seguro. Siga o princípio de menos permissões. A recuperação de dados usados em um relatório requer permissões definidas como somente leitura em fontes de dados. |
As URLs de relatório mostram os valores de parâmetro na barra de endereços da janela do navegador. |
Se um relatório tiver dados confidenciais, não adicione valores de parâmetro que possam ser violados na URL. Por exemplo, se um relatório com parâmetros inclui uma ID de funcionário, um usuário poderá inserir uma ID de funcionário aleatória na URL para exibir os dados desenvolvidos a outros usuários. |
Antes de publicar um relatório para distribuição final, analise a URL para verificar se os valores de parâmetro podem ser substituídos por valores aleatórios. Ao criar seus relatórios, lembre-se de que não há permissões associadas aos parâmetros de definição. Existe um par de possíveis atenuações:
|
Os relatórios e modelos contêm informações de fonte de dados e consultas. |
A divulgação de informações sobre uma fonte de dados ou sua estrutura fornece ao invasor informações internas que podem ser exploradas. |
Antes de permitir que um usuário modifique um modelo de relatório, defina a segurança do item de modelo para restringir o acesso aos itens de modelo que você não deseja que o usuário veja no Designer de Modelo. Defina as permissões nos arquivos. Entre eles estão os arquivos .rdl, .rds, .smdl, .ds, .dsv, and .smgl. Por padrão, se o sistema operacional for o Windows XP ou posterior, os arquivos que são armazenados localmente em uma pasta do usuário só poderão ser acessados por grupos de usuário e contas definidos no computador local. |
As definições de relatório e fontes de dados compartilhadas contêm cadeias de conexão da fonte de dados. É possível incluir credenciais em uma cadeia de conexão. |
Um invasor pode acessar as credenciais do banco de dados armazenadas na cadeia de conexão do banco de dados caso os arquivos de relatório sejam comprometidos. |
Armazene as credenciais separadamente da cadeia de conexão. Você pode usar a opção de credenciais armazenadas nas páginas de propriedade da fonte de dados para criptografar e armazenar uma conta de usuário e senha. |
Os relatórios e os modelos são processados sob demanda. Os relatórios podem conter ou fazer referência a assemblies personalizados. Eles podem conter itens de relatório personalizados ou controles de terceiros. Os controles de item de relatório personalizados exigem o modo Confiança Total. |
Um invasor convence um usuário a executar um relatório que explora o código interno do Visual Basic ou as consultas do banco de dados a executar códigos arbitrários com a permissão do usuário. Executar um relatório ou modelo que tenha sido violado pode fazer com que haja excesso de buffer, falha no servidor ou algo pior. |
Limite o número de usuários que têm permissão para publicar relatórios e modelos. Verifique se apenas os usuários autenticados têm permissão para transferir arquivos. Verifique se os usuários que criam relatórios sabem como criar scripts que possam opor-se aos ataques de injeção SQL, injeção de script e injeção de HTML. Só transfira ou publique relatórios e modelos de pessoas confiáveis. Só instale ou use um controle de item de relatório personalizado de pessoas confiáveis. Analise os arquivos antes de transferi-los para verificar se todas as referências aos assemblies personalizados são válidas. Defina as permissões de arquivo em assemblies de forma que eles não possam ser substituídos por usuários mal-intencionados. |
A visualização de um relatório ou modelo na guia Visualização no Designer de Relatórios criará dados em cache que podem ser recuperados usando as credenciais do autor. |
Os outros usuários que visualizarem um relatório no mesmo computador do autor do relatório terão a chance de exibir os dados do relatório que poderiam ser visualizados de outro modo. |
Implante os relatórios em um servidor de teste ou local ao concluir a criação de um relatório. |
Etapas gerais para reduzir ameaças e vulnerabilidades
Aplique as recomendações práticas recomendadas a seguir para aumentar a segurança global de qualquer implantação no servidor de relatórios:
Desative os recursos não utilizados para reduzir a área de ataque da superfície. Para obter mais informações, consulte Como ativar e desativar recursos do Reporting Services.
Use o SSL para as conexões do servidor de relatórios. Para obter mais informações, consulte Configurando um servidor de relatório para conexões SSL.
Crie uma hierarquia de pastas que ofereça suporte a diretivas de permissão avançadas substituindo os relatórios confidenciais nas pastas das ramificações subseqüentes da hierarquia de pastas nas pastas cujo acesso é permitido apenas a um conjunto restrito de usuários. Relatórios, modelos, fontes de dados compartilhadas e recursos que você publica em um servidor de relatórios são protegidos pelas atribuições de função que você cria em pastas e itens específicos no site do servidor de relatórios. Como a hierarquia de pastas é totalmente definida pelo usuário, cabe a você criar uma hierarquia de pastas capaz de agrupar todos juntos os itens que têm permissões de acesso de usuário semelhantes. Para obter mais informações, consulte Protegendo pastas.
Considere que os relatórios sob demandas são assemblies compilados que são executados em modo de confiança total em um servidor de relatórios com as credenciais do usuário que abre o relatório. Os usuários de relatório que efetuam logon usando as credenciais de administrador local ou de domínio e, subseqüentemente, abrem um relatório que contém scripts mal-intencionados, executarão esse script, inadvertidamente, com as permissões do administrador. Estimule os usuários a usarem contas de menos privilégios ao exibir relatórios. Para obter mais informações, consulte Segurança integrada e permissões elevadas.
Saiba como os dados são recuperados e usados em um relatório. Se um relatório tiver dados confidenciais, use os modelos como uma fonte de dados para que seja possível aplicar os filtros de segurança e a segurança do item de relatório. Para obter mais informações, consulte Tutorial: Aplicando filtros de segurança a itens de modelo de relatório.
Saiba como o relatório é distribuído. Os recursos de assinatura e entrega são técnicas poderosas para a automatização do processo de relatório e a distribuição do relatório gerado, mas para evitar acesso não autorizado, é preciso monitorar quem tem permissões compartilhadas nas pastas da rede e avaliar as definições da configuração de email do servidor de relatórios, determinando, assim, se é preciso restringir sua distribuição de emails. Para obter mais informações, consulte Controlando distribuição de relatório.