October 20, 2015 at 3:54 pm
I just began a new role as an SSRS developer, and am breaking away from my old ETL duties via SSIS. I say that to say I am not a complete neophyte, but I am not an advanced SSRS guru.
I have attached a screen shot that will help understand my question. When I bring up my report on the server I see the path to the specific report I am viewing. The rest of my team has gone out of their way to grant folder permissions from the front end application, but once the report is up they can also see the path at the top of the screen.
My question is how to eliminate this path. Is there a setting on the server level that will address this, or is there a setting on each report I can add to our new template? If this is not a viable solution, can someone direct me to some online training material that I can use to brush up on the security group settings where I can accomplish my goals? We are dealing with sensitive data that has a, "need to know only," allowance to use. As it stands right now someone could see reports they don't "need", and gain access to data they don't "need".
[font="Arial"]“Any fool can know. The point is to understand.”
- Albert Einstein
"DOH!"
- Homer Simpson[/font]
October 20, 2015 at 4:57 pm
Unfortunately, you can't do much about the Report Manager layout as the content is compiled into the application.
You can modify the CSS though, and if you were to add this to the default style sheet, it would hide the breadcrumb from view, but it would still be on the page for anyone with a modicum of knowledge to see.
[highlight="#ffff11"]Edit: Actually, it's late and I wasn't thinking - this particular style change comes from SQL 2016, you might need to find something similar for earlier versions.
[/highlight]
table.msrs-topBreadcrumb div a { display:none; }
It's a very crude hack and not secure, but you really want to consider not having the "private" stuff higher up the tree than the public stuff, that is pretty hard to secure in any environment.
The other option is to not use Report Manager for viewing reports, instead you can host the report viewer control on your own web page.
MM
select geometry::STGeomFromWKB(0x0106000000020000000103000000010000000B0000001000000000000840000000000000003DD8CCCCCCCCCC0840000000000000003DD8CCCCCCCCCC08408014AE47E17AFC3F040000000000104000CDCCCCCCCCEC3F9C999999999913408014AE47E17AFC3F9C99999999991340000000000000003D0000000000001440000000000000003D000000000000144000000000000000400400000000001040000000000000F03F100000000000084000000000000000401000000000000840000000000000003D0103000000010000000B000000000000000000143D000000000000003D009E99999999B93F000000000000003D009E99999999B93F8014AE47E17AFC3F400000000000F03F00CDCCCCCCCCEC3FA06666666666FE3F8014AE47E17AFC3FA06666666666FE3F000000000000003D1800000000000040000000000000003D18000000000000400000000000000040400000000000F03F000000000000F03F000000000000143D0000000000000040000000000000143D000000000000003D, 0);
October 21, 2015 at 10:02 am
Crude back hacks don't bother me. I don't care how pretty it looks on the back end just as long as it does what I'm looking for.
I want to make sure I understand what you were saying. You said that the CSS option is only available on SQL 2016. Is that the BI controls on VS 2016? Is that SQL Server Reporting Services on SQL Server 2016? I’m trying to isolate exactly what we’d need to upgrade. Our data lives on a SQL Server 2012 database, and we are using that same system to host the reports. We are using VS 2010 for our IDE.
Our reports have a website that will filter which links the end user can even see, and there are supposed to be controls in place that prevent folder access. I have not seen any data that points out a specific breach of our reports on the SSRS server, but with the breadcrumb trail showing at the top someone can theoretically click one of the upper links and instead of being taken back to the security controlled screen they are taken to the SSRS folder screens. From there they can drill down into any report.
The data we are trying to protect are simple items like SSN, tax records, and similar PII and PHI. These controls impact only company employees because the entire reporting system is still behind a password protected portal. We are dealing with state and federal policies that require the enhanced security, so this entire line of questioning is due to the beauty of bureaucracy. I just need to find A solution, and I don’t really know which options are in front of me. I hope the background makes the issue a little more clear.
[font="Arial"]“Any fool can know. The point is to understand.”
- Albert Einstein
"DOH!"
- Homer Simpson[/font]
October 21, 2015 at 1:14 pm
jarid.lawson (10/21/2015)
Crude back hacks don't bother me. I don't care how pretty it looks on the back end just as long as it does what I'm looking for.
It's not about it looking bad, the CSS "trick" would "look" good, but "be" bad for security, especially in light of your requirements. Why? Because you are just hiding it, but anyone who can right click and choose View Source can easily find the links you are hiding, they are still on the client page.
I want to make sure I understand what you were saying. You said that the CSS option is only available on SQL 2016. Is that the BI controls on VS 2016? Is that SQL Server Reporting Services on SQL Server 2016? I’m trying to isolate exactly what we’d need to upgrade. Our data lives on a SQL Server 2012 database, and we are using that same system to host the reports. We are using VS 2010 for our IDE.
Sorry for misleading you, the CSS style sheet is an option for 2012, I meant that 2016 has some new features in the Report Manager/Report Viewer that may include that specific CSS class name, but you should be able to identify the equivalent in 2012 if it is different.
Our reports have a website that will filter which links the end user can even see, and there are supposed to be controls in place that prevent folder access. I have not seen any data that points out a specific breach of our reports on the SSRS server, but with the breadcrumb trail showing at the top someone can theoretically click one of the upper links and instead of being taken back to the security controlled screen they are taken to the SSRS folder screens. From there they can drill down into any report.
Whether they can see the links or not, that sounds like a badly executed security implementation, which you should review. If the users are denied access to a specific folder, no amount of "monkeying" around should allow them to open the reports in that folder.
The data we are trying to protect are simple items like SSN, tax records, and similar PII and PHI. These controls impact only company employees because the entire reporting system is still behind a password protected portal. We are dealing with state and federal policies that require the enhanced security, so this entire line of questioning is due to the beauty of bureaucracy. I just need to find A solution, and I don’t really know which options are in front of me. I hope the background makes the issue a little more clear.
Those "simple" items are really rather important to the people that own them, and should be to you also.
I am not a security expert, and this sounds like it needs one, so I have nothing further to add, sorry.
Your OP sounded like more of a "Nice to have" than a legal requirement, so I felt able to chip in, but not any more.
Good luck and do post back if and when you resolve this.
MM
select geometry::STGeomFromWKB(0x0106000000020000000103000000010000000B0000001000000000000840000000000000003DD8CCCCCCCCCC0840000000000000003DD8CCCCCCCCCC08408014AE47E17AFC3F040000000000104000CDCCCCCCCCEC3F9C999999999913408014AE47E17AFC3F9C99999999991340000000000000003D0000000000001440000000000000003D000000000000144000000000000000400400000000001040000000000000F03F100000000000084000000000000000401000000000000840000000000000003D0103000000010000000B000000000000000000143D000000000000003D009E99999999B93F000000000000003D009E99999999B93F8014AE47E17AFC3F400000000000F03F00CDCCCCCCCCEC3FA06666666666FE3F8014AE47E17AFC3FA06666666666FE3F000000000000003D1800000000000040000000000000003D18000000000000400000000000000040400000000000F03F000000000000F03F000000000000143D0000000000000040000000000000143D000000000000003D, 0);
October 21, 2015 at 7:56 pm
There are two ways I can think of to address this aside from hiding the URL which would be a spectacularly bad idea.
SSRS has a web services with APIs you can call to add/remove user access per report. Once upon a time I wrote an SSIs package which looks at user settings in an application database (e.g. AD username and report they should be able to run) and then iterates through the SSRS APIs to grant/remove access to each report for each individual user. It would now be faster to re-implement in PowerShell.
Otherwise you can implement your own custom security provider which links into SSRS and takes over authentication (so in the background you'd have a plugin which authenticates it against the security settings in your application database); there was a sample in SQL 2008 but I don't think it's trivial unless you're a good programmer.
Viewing 5 posts - 1 through 4 (of 4 total)
You must be logged in to reply to this topic. Login to reply