After a couple of Google searches and a quick look at questions here, I cannot seem to find what I thought would be a cookbook answer for SQL Server permissions.
As I often see in small shops, most developers here were using an admin account for SQL Server while developing. I want to set up roles and permissions that I can assign to developers so that we can get our jobs done, but also do so with the minimum permissions required. Can anyone offer advice on what SQL Server permissions to assign?
Components:
SQL Server 2008
SQL Server Reporting Services (SSRS) 2008
SQL Server Integration Services (SSIS) 2008
Platforms:
Production
Staging/QA
Development/Integration
We are running "Mixed Mode" security because of some legacy apps and networks, but are moving to Windows Auth. I am not sure if that really affects the role set up.
I plan to set up access for Developers to Prod and Staging/QA DBs as Read-Only. However, I still want developers to retain the ability to run Profiling.
We need Deployment accounts with higher privilege levels. We are currently trying to figure out exactly what privileges we need for SSIS package deployments.
Within the Development Server, Developers need broad privileges. However, I am not sure that just making them all admins is really the best choice.
It's hard to believe that no one has published a decent example script that sets up these kinds of roles with a good set of appropriate permissions for developers and deployers.
We can probably figure this all out by locking things down and then adding permissions as we discover the need, but that will be way too big a PITA for everyone.
Can anyone point me to, or provide, a good exemplar for permissions for these kinds of roles on these kinds of platforms?
This will vary widely from company to company. The key ingredient is to lock down production so that devs cannot create or change objects. Our devs only have datareader rights on prod, nothing else. They can't even execute a stored proc unless logged into the application and using the application's permissions.
We give pretty much full rights to many developers on dev, but it might vary depending on which databases they are supposed to be developing against and which servers they are to access for the applications they support. So a dev with full access to one development server may not even have select rights on another.
By locking devs out of prod we have gained several critical things. First, there is no cowboy database development. They know they must create scripts for someone else to run and so they don't make random changes that they then forget about. This also means they are not a problem about putting the scripts into source control, since the people who do have rights to prod will only run a script if it is in Source control.
Next there are no people making on-the-fly emergency, untested changes to prod, that never get down to dev and qa and are thus lost the next time a new version is loaded up. As a result the changes that didn't work on prod have gone way down as well because now everything is tested before someone tries to put it on prod.
Nor are people making on the fly data changes to prod and accidentally updating the entire user table because they forgot to highlight a where clause (yes this happened before we locked down prod).
I've been searching for similar guidance but didn't find any. After some experimentation, I think a simple setup would be to add the user to the "dbcreator" server role, then add them to the "db_owner" role in each database they will be working on. This would allow the user to create new databases, as well as modify the ones in which they are a member of "db_owner."
Related
Apologies if this has been asked before - I couldn't find anything online.
I have some data in a couple of Excel spreadsheets that I need to clean, join, process etc. I would like to do this using SQL as the language is intuitive and easy to use. I currently have access to Oracle SQL Developer through my work computer, but it's not connected to any databases and I won't be able to do so for a while. I know that if I did have access to a database, I could simply upload the tables there, and then start working with them that way. Given that is not an option, I was wondering if there is anyway for me to create a local database just on my machine that I can upload those tables to and work with them that way?
Thanks!
Certainly. Go to Oracle Technology Network, download and install 18c Express Edition (XE). It is a lightweight database, fully operational and free to use. Make sure to read & follow installation guide.
Alternatively, go to apex.oracle.com and register (also for free). You'll get access to a database and the latest Application Express (Apex). Using its wizard, it is simple to create an application which will let you upload your files and work on them.
Also, there's Oracle Cloud Free Tier.
What would I do, if I were you? Install XE, probably.
Technically some of these other answers could work, but it sounds like you're working this as part of your job so you need to confirm a couple of things with your employer before diving in:
Most employers limit your ability to install software on your workstation or laptop. Oracle XE requires administrator privileges, so you need to confirm that your company will allow you to have that, and that they are ok with a database service running on a personal workstation. Many are not ok with that. Case in point: I do testing on my company laptop for various proof-of-concept things, but I'm not allowed to have admin privileges. I got special permission to install Oracle VirtualBox so I can work with some VMs, but that's it.
Given that you are working with company data, they may not be ok with you exporting that to a cloud service that they are not paying for (i.e. outside of their security boundary and legal oversight). If you plan to go that route, you need to make sure the company is ok with that approach too. My guess would be "not so much."
As far as creating a local database, you can't do that with Oracle without installing the software, which requires admin privileges. Also as I mentioned many companies have issues with installing software that creates network services (i.e. any database) on personal workstations because of the security implications.
Whatever you decide, just be sure what you're doing is legal with the powers that be.
I have an ASP.NET Web Application that is connected to a Database that is installed in several clients in production environment.
Some of those clients manage critical information (in other schemas, not accesible for the Web App, like people's money) so the access to execute scripts directly in the database to fix things in my Web App, if it's needed, requires time and also approbation, sometimes it takes weeks..
As some of my clients have a volatile reallity, my Web App has to manage a lot of changes in some short periods of time, that means script executions in the database to alter data or schema, and that means time waste !
Long story short, my question is, is it a good practice to implement a page, only for administrator users, that executes a raw query directly to database?
Think in the scenario where security issue is managed properly.
Something like: Sql Pad where you cannot see the entire database system, just the query and the result as the target database is only one.
No. It's a terrible idea. The security issue is probably not manageable - a web page that's available on the public internet which grants schema modification rights to the logged in user is a horrible security risk. Even if you can't get to another schema, you can easily bring the server to its knees by writing simple SQL which consumers all CPU, memory or disk space.
It's also terrible because you lose any track of what changes were installed in which environment.
If the IT department won't approve your scripts when run from management studio they certainly won't let you loose on your own via a web interface.
I've always solved this problem via automated deployment scripts - execute the schema changes etc. as a part of installing the new version of the web application. That way, you can do things like back up the database before running your changes, keep track of versioning and control access.
We have two environments - a dev environment and a production environment.
We have a different group of users in the development environment than the production environment, but there doesn't seem to be a good way to represent this in the database project - whenever we deploy it will wipe out the existing users, and we can only have one set - either the production users or the development users.
I thought of including scripts that switch based on SQLCMD variables to create the appropriate users, but that seems pretty nasty.
I feel like I'm missing some part of the database project, as this seems like a situation that will come up pretty well everywhere ever. Is there capability in database projects to handle creating different sets of users/role memberships in different environments?
There is an existing question about 2008R2 which seems to indicate not, but I'm optimistic that maybe there's been some changes in 2012 to provide this functionality.
Sadly, this is one area in which SSDT lacks. You'll need to build out your permissions and users differently. I've written up the method we've used here (with props to Jamie Thomson for the idea): http://schottsql.blogspot.com/2013/05/ssdt-setting-different-permissions-per.html
Basically we build out the permissions in a series of scripts and apply them depending on the variable passed to the SQLPackage command. That also gives us some flexibility with other areas, such as not running certain scripts in those environments, but it is a pain to set up the first time.
I am creating a 2-tier Lightswitch application which will be deployed via ClickOnce for single-user scenarios. The database schema and the data need to be protected from access by the users.
I know that this might not be perfectly possible, but are there ANY solutions to this?
We looked at a 3rd-party tool called DbDefence, and it seemed like a perfect fit, but their redistribution licensing pricing is way over our budget right now.
Much appreciated.
No, there's no way that I know of to prevent users from viewing or even fiddling with the database schema (if they're knowledgable enough). Unless you're creating the database for them, they have to have the permissions needed to be able to create the database. Plus updates (via Click-Once) would need update permissions on the tables.
The chances are, if you did find something, that it could prevent the application from working correctly anyway.
We have 18 databases that should have identical schemas, but don't. In certain scenarios, a table was added to one, but not the rest. Or, certain stored procedures were required in a handful of databases, but not the others. Or, our DBA forgot to run a script to add views on all of the databases.
What is the best way to keep database schemas in sync?
For legacy fixes/cleanup, there are tools, like SQLCompare, that can generate scripts to sync databases.
For .NET shops running SQL Server, there is also the Visual Studio Database Edition, which can create change scripts for schema changes that can be checked into source control, and automatically built using your CI/build process.
SQL Compare by Red Gate is a great tool for this.
SQLCompare is the best tool that I have used for finding differences between databases and getting them synced.
To keep the databases synced up, you need to have several things in place:
1) You need policies about who can make changes to production. Generally this should only be the DBA (DBA team for larger orgs) and 1 or 2 backaps. The backups should only make changes when the DBA is out, or in an emergency. The backups should NOT be deploying on a regular basis. Set Database rights according to this policy.
2) A process and tools to manage deployment requests. Ideally you will have a development environment, a test environment, and a production environment. Developers should do initial development in the dev environment, and have changes pushed to test and production as appropriate. You will need some way of letting the DBA know when to push changes. I would NOT recommend a process where you holler to the next cube. Large orgs may have a change control committee and changes only get made once a month. Smaller companies may just have the developer request testing, and after testing is passed a request for deployment to production. One smaller company I worked for used Problem Tracker for these requests.
Use whatever works in your situation and budget, just have a process, and have tools that work for that process.
3) You said that sometimes objects only need to go to a handful of databases. With only 18 databases, probably on one server, I would recommend making each Databse match objects exactly. Only 5 DBs need usp_DoSomething? So what? Put it in every databse. This will be much easier to manage. We did it this way on a 6 server system with around 250-300 DBs. There were exceptions, but they were grouped. Databases on server C got this extra set of objects. Databases on Server L got this other set.
4) You said that sometimes the DBA forgets to deploy change scripts to all the DBs. This tells me that s/he needs tools for deploying changes. S/He is probably taking a SQL script, opening it in in Query Analyzer or Manegement Studio (or whatever you use) and manually going to each database and executing the SQL. This is not a good long term (or short term) solution. Red Gate (makers of SQLCompare above) have many great tools. MultiScript looks like it may work for deployment purposes. I worked with a DBA that wrote is own tool in SQL Server 2000 using O-SQl. It would take an SQL file and execute it on each database on the server. He had to execute it on each server, but it beat executing on each DB. I also helped write a VB.net tool that would do the same thing, except it would also go through a list of server, so it only had to be executed once.
5) Source Control. My current team doesn't use source control, and I don't have enough time to tell you how many problems this causes. If you don't have some kind of source control system, get one.
I haven't got enough reputation to comment on the above answer but the pro version of SQL Compare has a scriptable API. Given that you have to replicate stuff to all of these databases you could use this to make an automated job to either generate the change scripts or to validate that the databases are all in sync. It's also not much more expensive than the standard version.
Aside from using database comparison tools, with 18 databases you should have a DBA, so enforce a policy that only the DBA can change tables at the database level by restricting access to CREATE and ALTER to the DBA only. On both your test and live databases. The dev database shouldn't have this, of course! Make the developers who have been creating or altering the schemas willy-nilly go via the DBA.
Create a single source-controlled DDL/SQL script for each release and only use it to update the databases. The diff tools can be useful but mainly for checking that you haven't made a mistake and getting out of trouble when the policies fail. Combine the DDL, SQL, and stored procedure scripts into a single script so that it's not easy to "forget" to run one of the scripts.
We have got a tool called DB Schema Difftective that can compare and sync database schemas. With our other tool, DB MultiRun you can easily deploy generated (sync) scripts to multiple db servers (project based).
I realize this post is old, but TurnKey is correct. If you are a developer working in a team environment, the best way to maintain a database schema for a large application, is to make updates to a Master Schema in what ever source safe you use. Simply write your own Scripting class and your Database will be perfect every time.