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.
Related
I have a rich client program installed on users PCs where I want to start storing some user created data on SQL Azure/SQL Server. The potential anonymous-to-me users would key in their name, email account and a password which would get stored on SQL Azure/SQL Server. Then they would start generating their own data. I'm anticipating volumes of maybe 1000 users.
There are times when those users would like to run their own queries against their own data but, obviously, I must ensure that they can never view other users data.
I'm thinking the best way to ensure security of data is for each user to be issued their own SQL Azure account and password. I will setup a SQL Azure user and long password, known only to me, which only has permissions to execute several stored procedures with appropriate parameters being passed to those SPs which will create the SQL Server accounts, logins and add the users to a role which I have created.
Obviously someone running debugging tools could figure out the user name and password but I'm thinking this isn't a big deal. If all that particular SQL Azure account can do is execute a few SPs so what if a malicious individual starts doing that. I will only allow a very limited amount of data to be uploaded before I require payment.
The users can only insert records using stored procedures which use the following:
SELECT #uName=SYSTEM_USER
and only select appropriate parent records. All stored procedures which users can execute would have the above as required to ensure they can only work with their own records.
All views will have embedded with them WHERE clauses such as
WHERE tbLoginName = SYSTEM_USER.
I'm new to SQL Server so I may be missing some fundamental concepts so I'd appreciate any and all comments.
The issue is, as pointed out on http://msdn.microsoft.com/en-us/library/ms189751.aspx:
In SQL Azure, only the server-level principal login (created by the provisioning process) or members of the loginmanager database role in the master database can create new logins.
Those accounts are also capable of alter and drop logins. So if you embed those accounts in the client application, you’re essentially granting every user permission to alter/drop other users accounts. While an average user won’t do that, a hacker will. So you cannot let a client application manage SQL Azure logins, unless only trusted users (such as your IT administrator) are permitted to use the app.
Best Regards,
Ming Xu.
I would like to point out a potential issue in the approach you mentioned: Your master SQL Azure account need to have privilege to create new accounts and grant them access to particular tables. This means your master account itself need to also have access to all those tables. If you store the master account on the client side, a clever user will get access to all users data.
From my experience, connecting to a database directly from a client side application will almost always make your solution less secure. You can do that for testing purposes, but in a real world solution, I would like to suggest you to use a service. You can host the service in Windows Azure. Then the service will access the database, and client application can only access the service. In this way, you can authenticate clients using any mechanisms you like, such as ASP.NET membership.
Best Regards,
Ming Xu.
You are essentially creating a physical two-tier database connection, allowing a client application to connect directly to the database. This is a problem in many ways, including security and performance. From a security standpoint, not controlling from where your customers will connect, you will need to keep your firewall rule wide open for anyone in the world to try to hack every customer uid/pwd. And instead of having only 1 user id to play with, hackers will have up to 1,000...
The second issue is performance. You applications will be unable to leverage connection pooling, creating undue stress on your database server and possibly hitting throttling issues at some point. Using a web service, with ASP.NET membership to manage logins, and using a service account (i.e. the same uid/pwd) to get data will ensure you will leverage connection pooling correctly if you keep the connection string the same for all your requests.
With a web service layer you also have a whole slew of new options at your fingertips that a two-tier architecture can't offer. This includes centralizing your business and data access logic, adding caching for improved performance, adding auditing in a centralized location, allowing to make updates to parts of your applications without redeploying anything at your customer locations and so much more...
In the cloud, you are much better off leveraging web services.
My 2 cents.
Let's say I want to create simple database, for a simple book store application. I think i should have minimum two users: admin, which has privileges to create, modify and drop objects and user, having just select and insert privileges.
I am a little confused here. Should I create a user account with normal schema or with empty schema? Should the user has privileges to select and query from admin schema which contains tables or it is a user schema that should contain these tables?
There are many different ways to approach this sort of problem. So a great deal depends on your application architecture.
You would generally create one database account that owns the database objects-- tables, packages, views, etc. Let's call this account BOOKSTORE_OWNER. This account would generally be locked so that no one could log in as BOOKSTORE_OWNER other during periodic builds.
Beyond that starting point, however, there are a host of reasonable ways to deal with authentication and authorization. If you wanted to let the database handle both, you would create two roles-- BOOKSTORE_USER and BOOKSTORE_ADMIN. Those roles would be given appropriate privileges on the objects owned by BOOKSTORE_OWNER. You would then create a database user for every person that can use the application and grant the appropriate role to each new user. So if you're an admin and I'm a user, the database account dygi would be created and granted the BOOKSTORE_ADMIN role while the database account Justin would be created and granted the BOOKSTORE_USER role.
This approach worked quite well when people were building client-server applications. If you are using a three-tier application, on the other hand, you want the middle tier connection pool to use the same credentials to connect to the database rather than having each user have their own database connections. The simplest way to accomplish this is to create a single BOOKSTORE_APP database account, grant that account all the privileges of the BOOKSTORE_ADMIN and BOOKSTORE_USER role, and then let the application implement the logic to figure out which front end user has what privileges. This would generally entail a USER, PRIVILEGE, and USER_PRIVILEGE table in the BOOKSTORE_OWNER schema. This approach can work quite well. The downside, though, is that every application has to build its own logic for managing privileges which can get quite complex over time. It also can make it somewhat difficult to report on what privileges users have or to ensure that a user's privileges are kept up to date when users leave the organization or move to a new role.
Oracle in particular addresses many of these challenges by allowing proxy authentication. This allows you to mix the benefits of the client-server approach where every user has their own database account that leverages Oracle's existing privilege management infrastructure with the connection pooling benefits of using a shared database account. This works very well but only works with Oracle and then only with certain protocols (OCI and JDBC) so it is not terribly popular.
Of course, beyond these basics, you can get into quite a bit of complexity. You may want to have enterprise users where Oracle doesn't maintain the password but instead allows the user to authenticate against an external LDAP directory. You may want to manage privileges with LDAP roles rather than with rows in application-specific tables. You may want to integrate with various middle-tier single sign-on (SSO) solutions.
I've done a piece of work using Entity Framework. However, my manager asked me to use Stored Procedures instead. He said at the moment, the database security structure in the company is built on database roles.
For example, we have a roleA which includes the AD users that will access the database, and roleA has only been given Execution rights to relavent Stored Procedures. If I use Entity Framework, queries will be run as the actual users instead of the database role, and therefore those users could potentially connect to the database directly and do something with it.
I'm not too familiar with the database security. Can anyone please explain whether what my manager said is valid?
If so, is there any workaround so that I can still use Entity Framework while not breaking the company's database security structure?(i.e. use role to execute the queries instead of actual AD users)
Database role is database level object. User account used to run your application must first log in to the server. Then the permissions for this account are evaluated based on database users or database roles. If your application account will be member of roleA it should have permissions "to access the database" but if the access means only that members of roleA can execute SP you can forget about any linq or ESQL queries because database security will simply not allow you calling them (it will throw security exception).
The only advantage of EF in such case is automatic mapping of SP's result set to entity / complex type / custom type. No linq-to-entities can be used and entities can be modified only through mapped stored procedures.
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.
We have some corporate intranet users using a WinForms app to work on a system with SQL server behind. Integrated Security is setup, allowing all users update and delete permissions, where application security limits how and where table updates take place.
However, some users are power users with SQL query tools at their disposal, and access the DB directly for building reports. However, with integrated security, they have default update rights on tables where they should not have, as the application apply rules to the updates.
Is this an example of where it's more appropriate providing the app with a central SQL authenticated login, whilst users get read only rights for integrated security?
As Jon mentioned stored procedures would give you the protection over direct table modifications. There are other options too. You can use SQL Server's "Application Role" (via sp_setapprole proc). This enables you to continue to use a separate ID for everyone but only at application connection time (through the front-end) are the user's rights elevated.
A major downside to using a shared ID is you lose track of who is submitting SQL to the server though if they're all internal you can get to the machine name.
Something else is concerning though. It sounds as if your users can connect to the database and run queries at will. You run a major risk of downtime in the application due to user behavior in the directly connected SQL sessions. If you can pull it off you may want to try to have a reporting database created that is updated at intervals that your business can tolerate, i.e., daily. HTH
I presume from the way that you've worded your question that your app executes sql statements directly. If you could refactor it so that it executes stored procedures, you could grant exec rights on the procedures and deny direct updating of the tables. This might not be possible though, depending on what your app does.
sql authentication is one option. Stored procedures are another. However, building more granular roles for assigning just the appropriate permissions to just the appropriate user types is where you should really be looking.
Additionally, I would really avoid giving these users direct access to the DB at all. Security reasons aside, it doesn't take much for a user who isn't proficient in SQL to accidentally execute a query that will swamp your database server and create an effective denial of service. Even pros can do this accidentally from time to time.
Instead, give them access to a reporting services or analysis services type solution, or use replication to give them access to a clone of the data. This way your production system is protected.
Personally I would do all application data access through stored procedures. I would set Integrated security to only allow users to run the SP's and not manipulate the data directly.
Advanced access can be given to DB admins to manipulate the data directly when needed.
Group based permissions will provide you with much more flexibility for access rights, and less administrative burden when controlling these with integrated security.