We are currently trying to make use of SSRS within my organization and I want to know how other organizations share these reports with the broader organization without having to give every individual rights to the SQL databases on the SQL server.
We have considered creating Active directory groups and then adding those groups as registered users under the databases but are having push back from IT related to possible data breaches when numerous users have access to a database.
If the groups only have read-only access then I don't know how much extra risk there would be.
What have other organizations done to allow individuals access to data without having to give individual access to each user?
There are two levels of permissions here - the permission to access the report and the permission to access the data.
You can setup data sources in SSRS as shared data source - and provide credentials that are stored securely in SSRS to access the data source. That can be a SQL account or Windows account (with windows account - you may need to set the account that runs SSRS to allow delegation).
When you build your report - setup the report to use a shared data source, the same name as the shared data source created in SSRS and make sure you do not allow overwriting the data sources in your project. When you then publish the report - the report will be published to use the shared data source and will not overwrite the one that already exists.
Now - you can create your AD groups and use those groups to grant access to the folder/report in SSRS. The users who have access to the reports will be able to run the reports but will not have direct access to the database system.
Related
The Problem
Good Morning! I work on an application team that supports a few applications which utilize SQL Server for data storage. Recently, our Database Support team decided that SQL Authentication was no longer permissible (for security and logging reasons) and so my team was forced to convert all connections to Windows Authentication including several dedicated Service IDs that our applications had been utilizing for data retrieval.
First, let me say there most certainly are advantages to moving to Windows Authentication, I am not trying to dispute that. But this change has raised a huge problem for us... by switching our Service IDs to Windows Authentication we have now opened up our back-end databases to every internal business user with front-end application access.
MS Access is pushed out to every user desktop and a few superusers even have access to SSMS. At this point we are relying entirely on user ignorance to prevent internal users from accessing the back-end database directly. And given that certain roles have elevated DML rights, this presents a possibility for some nasty data consequences.
This new enterprise standard has left my team stuck between a rock and a hard place at this point so we looking for any database, account or architecture solution that would allow us to restrict user access to front-end only.
Questions
Has anyone else run into this problem? Is there an architectural solution we are missing that would allow us to eliminate SQL Authentication without exposing our databases?
Does anyone know of a way to restrict access to a SQL Server database to only certain connection methods? I'm wondering if there is a way to designate a specific ID (or role) as only allowing a connection through a front end (and eliminate ODBC connections entirely).
Does anyone have any clever workarounds?
-------------EDIT---------------
A couple people brought up a good point about role access so I wanted to clarify our former and current solution... Previously, all role access was managed on the front-end and data retrieval was handled entirely by private system SQL Authenticated IDs to which end users had no visibility.
When we were forced to eliminate these SQL Auth IDs, we created a similar role-based setup on the back-end database as existed on the front end. Active Directory Groups were created to house different groups of users and these groups were assigned specific role privileges in the database. So currently access is limited by role as much as feasible.
The problem is that even the lowest privileged roles have INSERT, UPDATE and DELETE access to some tables (access which is normally controlled through code). So while we were able to mitigate risk somewhat by utilizing database roles, we still have areas where a user can bypass front end protections by logging directly into the database.
EDIT: Question clarification makes this answer obsolete, but leaving it for reference since some comments discuss it.
Assuming you mean that you have to (based on your architecture) allow access to the DB to each windows user account, one options is to use database roles.
You disable public access to your database, then define a set of database roles, depending on your use cases. Each role is granted permissions such that members of that role are able to manipulate the data they need and or work with the objects they need. Users are then mapped into the roles they require. When connecting to your database, the user will be granted permissions according to the roles they are members of.
For example, we have a role in one of our databases named MyAppUser (our name is actually related to the app which uses the db), which is designed for end users to read and insert data only. These can be created simply as follows:
CREATE ROLE [MyAppUser]
The role is granted just the permissions it to the relevant schemas or tables (assume all our "public" tables are in dbo schema for now).
GRANT SELECT ON SCHEMA::[dbo] TO [MyAppUser]
GRANT INSERT ON SCHEMA::[dbo] TO [MyAppUser]
GRANT DELETE ON SCHEMA::[dbo] TO [MyAppUser]
Each user who should have this public read-write access is then mapped into the relevant role.
ALTER ROLE [MyAppUser] ADD MEMBER [UserName]
This separates users and roles / permissions within your database and allows you to have a single point of entry to control who has access to what in your databases.
By having the "View Definition" permission denied by default (to end users), they won't be able to "explore" the database / view table definitions etc using access, or even SSMS.
NB: SSMS provides wizards for managing and viewing permissions and memberships which are very handy for getting things initially setup / tested / fiddled around with.
I researched through Stackoverflow and some tutorials but cannot find an information on whether it is possible to configure the account under which the Reporting Services are running to have the permissions of an application role which is set on the source database? For example, I created a specific application role on the database for the reports and report builder to only being able to query certain schemas. How do I force the Reporting Services to use that role when connecting to that database as its source?
I want to make this work in Reporting Service itself. Because when the client deploys our reports, by default my database is the source for all of those reports. So it makes sense, for security reasons, to make sure that all deployed reports can only access what they should be accessing. And if a client decides to add a new report - they only have access to certain schemas that they can query.
I looked under the Security drop-down option from the data source, but see no way of configuring it to work against the application role.
Because this has proven impossible in a simple way. And the problem that we do not know the account SSRS (deployed data source and the reports) will be deployed under on the client's environment. The specific role will be added as Database Role, and the membership of which will have to be set upon the manual configuration on the client's environment through the application.
i have an ASP.net (.net 4, c#) web application (Backend: SQL Server 2012). The permission concept (what data is each user allowed to see) is processed within the web application.
The permissions come from different sources:
-AD group memberships:
AD group name is linked to properties of the records
-Underlying database:
-Users are assigned to different criteria
Organizational structure
Location structure
Direct assignment
Currently all this is processed within the web application. So I collect all the users permission and then I query the database for the data he is allowed to see.
Now I need to bring the permission concept to database level.
The target is that the users can query the database (pre defined views) almost directly (Reporting Services, Excel and so on)
Any idea how to solve such an issue?
Thought about joining the user’s permission on the foreign keys. But that’s not possible for the AD permissions.
Or maybe creating a dll and calling this dll from a stored procedure. Then the view joins the stored procedure.
You should look at defining roles in the database http://msdn.microsoft.com/en-us/library/ms188659.aspx .
Then grant permissions on different tables or views depending upon your requirement. I have seen data being exclusively read from views. So, that could also be an option.
EDIT:
So, it looks like you need row level security. Please read this guidance from Microsoft.
http://technet.microsoft.com/en-us/library/cc966395.aspx
I have a customer who wants to run all their reporting in Access but they need data from my SQL Server database and I need to be able to filter what data they see by a few parameters. The data needs to be updated frequently, what is the best way to handle this.
You could create a login with read permissions on your prod db, or a login with read permission on "publication db" where you would copy the visible info nightly.
Your question needs to be more precise in terms of timing (real time info or not) and granularity (all details or summarized data), at least.
My suggestion would be to create Views that do any permanent filtering (that is, that filter what you allow the Access user to see). Then create a login with Read on those Views.
From the Access end, link to the Views with Get External Data (by whichever method applies to the Access version), for an ODBC Connection, which contains the login credentials if you're not using Integrated Security on the SQL Server. The Views show up as tables & the user can report to their heart's content.
I'm building a Windows application that will go against a SQL 2008 database. Some of the table data is very sensitive but some of our users will still need at least read if not read/write access to those tables. We're going to use Windows Security to control their access to the database.
I want to know if those same users can access the data in those tables through something like Excel or MS Access? It's about blocking a bad apple from trying to steal the data inside and walking off with it. If they have read access to the data, though, is there any real way to stop them?
Sorry if this is a SQL Server 101 question, but I'm not finding good answers to the question.
Thanks for the help!
If they have to have read access, then you should pretty much assume they can do what they want with the data. If you render data on the screen, you have to assume someone can write down what they see with a paper and pencil.
With that said, I'd create a service account that has permissions to access SQL Server from your application. Control the access in your app via roles. Do not grant any users access to your database directly - they have to go through your app.
If you try to open Access or Excel and point it to your SQL Server database, they won't have permission to do anything.
A good way to do this might be to author stored procedures that fulfill all of your needs and grant all the users execute only privileges.
If you grant full read access to your users, then yes its going to be difficult to prevent them from what your talking about.
As mentioned by others, you can create a SQL account for your application. This will disallow any outside access from anything other than your application itself. Of course, this would mean that access to your application itself would have to be restricted. This is also easily accomplished by limiting read access to the executable to an active directory group which contains users whom get access. Further to that, you application may also use active directory hooks to determine whether to allow write access for those users who need it.
That all being said though.... your biggest problem will be the physical security. If just one user in the authenticated group is untrustworthy, then a certain acceptable usage policy, HR employee screening, and user environment checks and balances must be in place. A proper workstation deployment policy will also be good here, allowing you to restrict removable drive usage, logging all access, connectivity details etc etc.
It's more about the operational environment at this point if you can't trust the user.
Users could access SQL tables using linked table in Access or external data query in Excel, however the permissions are controlled by the SQL server, which means the users have read-access, they will be able to access data in read-only mode.