What's a good way to manage and maintain SQL Server logins, server roles, and individual access rights across multiple databases that exist in multiple environments? What are your best practices?
Some info about my situation:
SQL Server 2005
We have N amount of "client" databases with identical schemas (in theory, at least)
We have a central "admin" database that references each client database and can hold configuration values
This "admin/client" pattern is duplicated across multiple environments (dev/qa/stage/prod)
Some users, like testers, need different rights based on evironment
We frequently have to pull client db backups from one environment to restore on another for development or testing purposes
We keep our stored procedures and scripts in source control and deploy in a build cycle
Right now my organization is chaotic and we don't follow good security practices. We have no formal DBA. However, if we got any more complex it would be a constant hassle to maintain it all the time. I could see migrating to a new server or recovering from disaster being extremely time consuming if we where to attempt configuring it directly through the management studio IDE.
First, to make restoring a database to a different server easier, make sure that your logins all have the same SID on all of your servers by using the sp_help_revlogin stored procedure from Microsoft to script the login on the first server you create it on and then use the script to create the login on your other servers. This keeps the database user mapped to the login correctly when you restore the database.
Having different permissions at the database level depending on the environment is going to be a hassle to a point no matter how you role this out. I have a stored procedure in master that gets called on my Dev Server as a part of my restore process that performs the additional GRANT's on the database to give the developers access to make changes. That's the best I have been able to come up with to solve similar problems.
A way to make the rights easier would be to create rolls in the database called Dev, QA, Test, Prod and grant the correct rights to those roles. Then as you restore the databases to each environment just drop the developers in the correct role.
We use active directory groups and enforce windows authenticated logins. From within SQL Server we can then define access based on the AD group the user is in by creating a single SQL Server login per AD group. Not sure if this is any better or worse than DB roles, but it means the roles are managed outside each database.
Propagating access to databases is then either a manual operation or a short SQL script to ensure the logins in the database point to a valid SQL Server login (which in turn is an AD group).
Generally this works well for the general case. We can use DB roles then to assign the builtin roles (e.g, db_datareader) to each AD group
Rarely someone needs some specific access to a database outside this model. We either end up opening it up to the group as a whole if it's not going to be invasive or critical or we'll end up creating a per-user account that has to be managed separately. We endevour to keep these to an absolute minimum, and clean them up every now and then so they're not abused/forgotten about.
Related
Thanks in advance for reading!
Note: I've read everything else I could find about this on SO, but don't see this particular question asked.
I don't want to muddy (or break) our 3rd party production ERP database ("B") with objects of my own, so I created a database ("A") in another instance and use it as the home of various objects that serve our custom applications.
I have a stored procedure in A that selects from tables in B, and returns a dataset. It works beautifully for me from my app using Windows authentication, because I am an admin on both servers. But I am one of the rare users who have Windows Authentication in the ERP db. By default, users in the ERP are created with SS authentication.
If it's a reasonable practice (and because maintenance of my objects would be simpler than with certificates), would it make sense/be possible to create a SQL authenticated user on A (and maybe B) that has execute permissions on the sp in A and read permissions on tables in B?
If not, and in order to avoid dealing with certificates whenever I modify a procedure, I'll probably create server logins on A and B for new Active Directory groups, and create database roles for the groups.
Thanks again for your interest!
I'm making an Access database which will be used by multiple people, but I want to make it so that only certain people can edit,add,delete certain tables or fields so data isn't accidentally changed wrongly, and so the data is read-only to the people who don't have permission to edit. Is there any way to do this? Could I even just have access to certain tables or forms password protected?
Access used to have its own security model using an MDW file, but that went away sometime ago. So the short answer is "no". If you are able to introduce SQL Server into the equation, you could store the tables in SQL (or the free version SQL Express). SQL Server offers the security model you need, and you would then link the tables from SQL Server (ODBC) to Access. In this model, SQL Server is managing your data, and Access is your "front end". Once linked, access forms, reports, etc. really don't distinguish between local or attached tables, so all of your same Access skills apply. You can export the tables from Access to SQL using the export feature within Access, and choose ODBC. I'm not sure if you're comfortable doing this, but it's really not all that difficult.
If you do use SQL Server (or Express) you would configure the users and permissions on the tables themselves, using SQL Sever Management Studio. If a user that did not have update permissions, for example, tried to update a row from an Access form, Access would fire the statement at SQL Server which would return a permission error. You could also use SQL Security to implement Windows Authentication, and assign permission to network users. When the statements were fired at SQL Server, they would be authorized based on the users login (when they logged into the network). There would be no need for them to login again.
If you decide to go this way, let me know and I can guide you through it.
I have inherited a SQL Server box with a series of databases and it has Windows Auth for creation/maintaining the well-baked and established databases. The box itself has many other services which require a user to login as admin to maintain.
I now have to create a new database on the server that only a select few in the company, including IT, will have access to. So I'm kind of chasing my tail on the best place to start.
I want to continue to give the guys the admin level access they require to all the other stuff on this box but limit them on SQL Server options so I can better manage the databases and secure them. What might be the best way to unwind the Windows Authentication method and dole out databases / create opportunities for those users while securing new databases they should not access? Am I even going in the right direction by deviating from the Windows Auth method?
One of the primary reasons for creating a second instance on a server is security. By creating a second instance you basically re-start security over again. So this is an option you might consider for your new database. IE Creating a second instance and putting the "secure" database on it.
A few things you should also consider.
First, yes you should unwind your security as possible and give out the minimum security required for any given user/group. This is a best practices thing. Never give out dbo or sysadmin permissions without an explicit reason to do so, and even then question it thoroughly to make sure that there isn't some other way around the problem. Never give out more permissions than are absolutely required.
Second, It is almost impossible to keep the administrator of the server the instance is on out of the instance if they really really want to get in. And I only say "almost" impossible because there may be a way that I don't know about. At the level of administrator for the server, or domain administrator for that matter you have to assume they can be trusted not to try to break in. You probably won't be able to keep them out anyway.
Last but not least if you can move your instance off of a server that has many other services which require a user to login as admin to maintain. This is a security nightmare first of all (as I said above) and second your SQL server will work better on it's own server. I've even heard advice from experts that say you should never remote into the server a SQL Server instance is on. And if you have to remote in definitely don't copy files around while remoted. Generally said the less going on on the server the happier SQL is.
You can remove the domain administrators ability to access the SQL Server by removing the BUILTIN\Administrators group from the SQL Server logins.
I wouldn't recommend moving away from Windows Authentication, as you would create a whole new set of security concerns you then would have to deal with.
Domain admins can
add themselves to any group (local or domain) that has has access to SQL Server
change the service account policies and log in with that
change SQL server to use a service account in case it uses a built in account
use any user account that has SQL Server access
change password to allow this
Do anything in the domain. At. All.
SQL Server always has Window Auth switched on so it is always available to Domain Admins
If it's that sensitive then it needs to be in separate domain or standalone or something.
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.
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.