Nota
O acesso a esta página requer autorização. Pode tentar iniciar sessão ou alterar os diretórios.
O acesso a esta página requer autorização. Pode tentar alterar os diretórios.
Importante
Um relatório não é uma barreira de segurança. Conceder a um utilizador acesso a um relatório pode também expor dados da fonte de dados do relatório para além do que consta no relatório. Impor o acesso a dados na fonte de dados – por exemplo, usando segurança ao nível da linha ou ao nível do objeto num modelo de Serviços de Análise, ou permissões de base de dados numa fonte relacional – e não escondendo itens do relatório. Controlos ao nível do relatório, como permissões de pasta, atribuição de funções e parâmetros ocultos, governam o acesso ao relatório, e não aos dados que este pode devolver.
Pode definir a segurança para relatórios e recursos individuais para controlar o grau de acesso que os utilizadores têm a esses itens. Por defeito, apenas os utilizadores que são membros do grupo integrado de Administradores podem executar relatórios, visualizar recursos, modificar propriedades e eliminar os itens. Todos os outros utilizadores devem ter atribuições de funções criadas que permitam o acesso a um relatório ou recurso.
Acesso baseado em funções a relatórios e recursos
Para conceder acesso a relatórios e recursos, pode permitir que os utilizadores herdem atribuições de funções existentes de uma pasta pai ou criem uma nova atribuição de função no próprio item.
Na maioria dos casos, provavelmente queres usar as permissões herdadas de uma pasta pai. Definir a segurança em relatórios e recursos individuais só deve ser necessário em alguns cenários. Esses cenários são:
- Se quiser esconder o relatório ou recurso de utilizadores que não precisam de saber que o relatório ou recurso existe
- Para aumentar o nível de acesso a um relatório ou item.
Estes objetivos não são mutuamente exclusivos. Pode restringir o acesso a um relatório a um conjunto menor de utilizadores e fornecer a todos ou a alguns deles outros privilégios para gerir o relatório.
Pode ser necessário criar múltiplas atribuições de funções para alcançar os seus objetivos. Por exemplo, suponha que tem um relatório que quer tornar acessível a dois utilizadores, Ann e Fernando, e ao grupo de Gestores de Recursos Humanos. Ann e Fernando têm de conseguir gerir o relatório, mas os membros dos Gestores de Recursos Humanos só precisam de o gerir. Para acomodar todos estes utilizadores, criaria três atribuições de funções separadas: uma para tornar a Ann gestora de conteúdos do relatório, uma para tornar o Fernando gestor de conteúdos do relatório, e uma para suportar tarefas apenas visualizadas para o grupo de Gestores de Recursos Humanos.
Depois de definir a segurança num relatório ou recurso, essas definições mantêm-se no item mesmo que o mova para um novo local. Por exemplo, se mover um relatório ao qual apenas algumas pessoas estão autorizadas a aceder, o relatório continua disponível apenas para esses utilizadores. Este resultado pode acontecer mesmo se o mover para uma pasta com uma política de segurança relativamente aberta.
Mitigação de ataques de injeção de HTML num relatório ou documento publicado
No Reporting Services, os relatórios e recursos são processados sob a identidade de segurança do utilizador que está a executar o relatório. Se o relatório contiver expressões, script, itens de relatório personalizados ou assemblies personalizados, o código corre sob as credenciais do utilizador. Se um recurso for um documento HTML que contém script, o script é executado quando o utilizador abre o documento no servidor de relatórios. A capacidade de executar scripts ou código dentro de um relatório é uma funcionalidade poderosa que traz um certo nível de risco. Se o código for malicioso, o servidor de relatórios e o utilizador que executa o relatório ficam 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 total confiança e que um script potencialmente malicioso pode ser enviado ao cliente. Dependendo das definições do navegador, o cliente executa o HTML ao nível de confiança especificado no navegador.
Pode mitigar o risco de executar scripts maliciosos tomando as seguintes precauções:
Seja seletivo ao decidir quem pode publicar conteúdo num servidor de relatórios. Como existe potencial para publicar conteúdo malicioso, deve limitar os utilizadores que podem publicar conteúdo a poucos utilizadores de confiança.
Todos os editores devem evitar publicar relatórios e recursos que provenham de fontes desconhecidas ou não confiáveis. Se necessário, abra o ficheiro num editor de texto e procure scripts e URLs suspeitos.
Parâmetros de relatório e injeção de scripts
Os Parâmetros do Relatório proporcionam flexibilidade para o desenho e execução global do relatório. No entanto, esta mesma flexibilidade pode, em alguns casos, ser usada por um atacante para atrair ataques. Para mitigar o risco de executar scripts maliciosos inadvertidamente, apenas abra relatórios renderizados de fontes confiáveis. Deve considerar o seguinte cenário que é um potencial ataque de injeção de script HTML Renderer:
Um relatório contém uma caixa de texto com a ação de hiperligação definida para o valor de um parâmetro que pode conter texto malicioso.
O relatório é publicado num servidor de relatório ou disponibilizado de forma a que o valor do parâmetro do relatório possa ser controlado a partir da URL de uma página web.
Um atacante cria um link para a página web ou servidor de relatórios. Esse link especifica o valor do parâmetro no formulário
javascript:<malicious script here>e envia esse link para outra pessoa num ataque de atração.
Mitigar ataques de injeção de scripts num hiperlink num relatório ou documento publicado
Os relatórios podem conter hiperligações incorporadas no valor da propriedade Ação num item de relatório ou numa parte de um item de relatório. As hiperligações podem ser atribuídas a dados que são recuperados de uma fonte externa quando o relatório é processado. Se um utilizador malicioso modificar os dados subjacentes, o hiperlink pode estar em risco de explorações de scripting. Se um utilizador selecionar o link no relatório publicado ou exportado, pode ser executado um script malicioso.
Para mitigar o risco de incluir ligações num relatório que inadvertidamente executam scripts maliciosos, apenas associe hiperligações a dados de fontes confiáveis. Verifica que os dados dos resultados da consulta e as expressões que ligam dados a hiperligações não criam ligações que possam ser exploradas. Por exemplo, não baseie um hyperlink numa expressão que concatena dados de múltiplos campos de conjuntos de dados. Se necessário, consulte o relatório e use "Ver Fonte" para verificar scripts e URLs suspeitos.
Mitigar ataques de injeção SQL num relatório parametrizado
Em qualquer relatório que inclua um parâmetro do tipo String, certifique-se de usar uma lista de valores disponíveis (também conhecida como lista de valores válida) e assegure que qualquer utilizador que execute o relatório tem apenas as permissões necessárias para visualizar os dados no relatório. Quando você define um parâmetro do tipo String, o usuário é apresentado com uma caixa de texto que pode ter qualquer valor. Uma lista de valores disponíveis limita os valores que podem ser introduzidos. Se associares o parâmetro de relatório a um parâmetro de consulta e não usares uma lista de valores disponíveis, é possível que um utilizador de relatório escreva sintaxe SQL na caixa de texto. Esta ação pode potencialmente expor o relatório e o seu servidor a um ataque de injeção SQL. Se o utilizador tiver permissões suficientes para executar a nova instrução SQL, pode produzir resultados indesejados no servidor.
Um parâmetro de relatório pode não estar ligado a um parâmetro de consulta e os valores dos parâmetros estão incluídos no relatório. Se for esse o caso, é possível que um utilizador de relatório escreva a sintaxe de expressão ou uma URL no valor do parâmetro e reproduza o relatório para Excel ou HTML. Se outro utilizador visualizar o relatório e selecionar o conteúdo dos parâmetros renderizados, o utilizador pode executar inadvertidamente o script ou ligação maliciosa.
Para reduzir o risco de executar scripts mal-intencionados inadvertidamente, abra relatórios renderizados somente de fontes confiáveis.
Note
Em versões anteriores da documentação, foi incluído um exemplo de criação de uma consulta dinâmica como expressão. Este tipo de consulta cria uma vulnerabilidade a ataques de injeção SQL e, por isso, não é recomendado.
Garantir relatórios confidenciais
Relatórios que contenham informação confidencial devem ser protegidos ao nível do acesso aos dados, exigindo que os utilizadores forneçam credenciais para aceder a dados sensíveis. Para mais informações, consulte Especificar informações de credenciais e ligação para fontes de dados de relatório. Também pode proteger uma pasta para a tornar inacessível a utilizadores não autorizados. Para mais informações, consulte Pastas Seguras.