Acontece que estou configurando um servidor de relatórios no trabalho desde o início. Tendo muito pouca experiência em administração de servidor SQL, estou achando muito difícil definir as configurações de segurança para o Gerenciador de Relatórios.
Entendo que todos os usuários que acessarão o Gerenciador de Relatórios precisarão de permissões em Dois Níveis
1 – Permissão para acessar dados do sql server. (para o qual, após algumas pesquisas, decidi usar a função datareader.
2- Permissão para acessar o gerenciador de relatórios para o qual tenho a opção de escolher entre as funções do gerenciador de relatórios, como (navegador, gerenciador de conteúdo etc etc.)
Para o gerenciador de relatórios, criei uma nova função apenas com permissões para visualizar relatórios.
Problema
Com todos esses filtros de segurança em vigor, quando adicionei uma conta de usuário de domínio ao Gerenciador de relatórios, o usuário pode navegar em qualquer lugar no Gerenciador de relatórios (pode acessar pastas, DataSources e relatórios para os quais não tem permissão).
Não desejo que os usuários exibam fontes de dados ou quaisquer outras pastas ou relatórios para os quais não tenham permissão.
O que eu tentei até agora
1- Adicionado um usuário a uma pasta no gerenciador de relatórios, mas eles podem navegar para qualquer outra pasta no gerenciador de relatórios.
2- Adicionado um usuário a apenas um relatório, novamente eles podem navegar para qualquer outra pasta no Gerenciador de relatórios.
3- Eu estava usando uma conta virtual para SSRS Service Account, removi isso e tentei em todas as outras 3 contas integradas para conta de serviço, LocalService, LocalNetwork e LocalSystem. (Não tenho certeza se isso teria feito diferença).
Todos esses esforços em vão, pois, sempre que um usuário é adicionado a qualquer relatório ou pasta, ele pode navegar para todas as outras pastas e relatórios e pode realmente executar relatórios.
Os usuários tinham a função de leitor de dados atribuída no Sql Server e uma função personalizada no Gerenciador de relatórios, que tinha permissões apenas para exibir relatórios.
Configurei os serviços de relatórios para usar a autenticação padrão do Windows. é Sql
Serviços de relatórios do Server 2008 R2. Data Center Edição.
Por favor, qualquer conselho ou qualquer direção seria uma grande ajuda. Eu tenho lido o BOL, mas nada ajudou ainda.
Normalmente, no SSRS, você usaria a interface de gerenciamento do SSRS (/ReportsManager IIRC) para definir as funções/permissões do usuário por pasta. Eles são normalmente herdados por subpastas, embora você possa substituir isso. A função 'browser' é mais apropriada para usuários finais, pois permite executar/visualizar relatórios, mas não muito mais. Se você conceder a um usuário acesso de 'navegador' para a pasta, mas não para B, ele não poderá acessar a pasta B, a menos que seja uma subpasta de A (por padrão, concedida as mesmas permissões de A) ou a menos que B seja uma subpasta -folder de outra pasta à qual o usuário tem acesso de 'Navegador'.
Você provavelmente não deveria conceder direitos aos usuários do domínio diretamente no SQL Server. As várias contas que o próprio SQL Server usa, bem como as contas administrativas, devem ser configuradas no SQL Server. O acesso do usuário final ao SSRS é controlado pelo SSRS com base nas regras inseridas no SSRS.
Ao criar seu relatório no SSRS, você deseja configurar a fonte de dados com uma conta com privilégios adequados no banco de dados para executar o relatório (em sua fonte de dados em credenciais). Normalmente, usamos uma conta de serviço para isso, a menos que seja necessária uma segurança mais alta. Eu vi onde isso cai depois de implantar um relatório no servidor de relatório, então é sempre bom verificar a fonte de dados no servidor de relatório e certificar-se de que a conta ainda está lá.
Então, você está adicionando o acesso do navegador à própria pasta raiz? Nesse caso, é por isso que essa conta pode exibir todas as pastas no servidor de relatórios, se cada pasta no gerenciador de relatórios está herdando permissões, é por isso que elas podem acessar mais. Eu removeria esse usuário da pasta raiz e tentaria adicionar esse usuário com permissões de navegador à pasta que você deseja que ele visualize.
Algumas vezes, ao alterar as permissões dos usuários, as novas configurações não serão aplicadas a uma conta, a menos que eu a remova completamente e, em seguida, configure-a novamente apenas com acesso ao navegador.
Esta não é uma resposta completa, mas não recomendo ter relatórios ativos passando as credenciais do usuário para o SQL Server.
Suponha que um desenvolvedor de relatórios mal-intencionados crie algum tipo de relatório que faça coisas desagradáveis que exigiriam privilégios de administrador do sistema (vandalismo, concessão de privilégios, qualquer coisa). Basta implantar o relatório e enganar alguém com sysadmin para executá-lo (CSRF pode ser suficiente para executar o "relatório", embora eu nunca tenha tentado), e pronto, seu código está sendo executado com direitos de sysadmin.
A abordagem que usamos é selecionar a autenticação do Windows nas fontes de dados no Visual Studio. Os desenvolvedores podem, assim, criar relatórios com base em qualquer coisa a que tenham acesso. Todas as fontes de dados são implantadas em um único local ("/Data Sources", naturalmente) e essas cópias das fontes de dados são configuradas com credenciais estáticas. Como o Visual Studio não substitui as fontes de dados por padrão ao implantar projetos de relatório, tudo funciona bem, desde que não esqueçamos de conceder permissões à conta que acessa os dados, como sempre faço.
Agora, de volta ao problema de permissões excessivas. Por padrão, qualquer objeto (pasta, relatório etc.) criado no Reporting Services será definido para herdar permissões de seu pai. É semelhante às permissões de arquivo do Windows, embora um pouco mais simples no geral - as permissões de um objeto devem ser todas herdadas ou definidas explicitamente. Pronto para uso, o Reporting Services tem algumas funções padrão que você pode conceder aos objetos. Se você quiser obter mais detalhes e personalizar as funções, use o Management Studio: no Pesquisador de Objetos, conecte-se ao Reporting Services e especifique a URL do serviço Web do servidor de relatório como o nome do servidor. Faça uma busca detalhada em Segurança, Funções e você poderá personalizar ou adicionar funções conforme necessário.