I created SQL DB. and I want to allow only "DB owner" to access stored procedures. I want to prevent all other users including 'sa' user from doing that . how to do that ?
short answer: you can't.
long answer: sa is the owner of the whole server so cannot be cut out of anything on the server. you can prevent all other users (that does not have a sysadmin role) from using the stored procedures but again you have no way to lock out sa and/or any user with sysadmin role.
you may revoke permission to SA but SA can grant these permissions back easily.
actually you may lock out SA user if you disable SQL authentication or disable the user but anyway you cannot prevent other users with sysadmin role to interact with the stored procedures: this is by design.
please post a question with the actual requirement: this question looks like a solution you are trying to implement; maybe we can help you find a suitable solution for the actual issue.
as a side note, if you don't trust the admin of the server there is something wrong...
Related
When I scan my database, it shows one of the result like VA1143 'dbo' user should not be used for normal service operation in A Vulnerability Assessment scan
They have suggested to "Create users with low privileges to access the DB and any data stored in it with the appropriate set of permissions."
I have browse regarding the same to all form but cannot get the correct suggestion yet. Could you please suggested your idea or where i have to create the user and grand the permission. Since we have only one schema structure in our DB.
About "Create users with low privileges to access the DB and any data stored in it with the appropriate set of permissions.", the first thing you should know is the Database-Level Roles.
Create users with low privileges means that the use does not have the alter database permission.
When we create the user for the database, we need to grant the roles to it to control it's permission to the database.
For example, bellow the the code which create a read-only user for SQL database:
--Create login in master DB
USE master
CREATE LOGIN reader WITH PASSWORD = '<enterStrongPasswordHere>';
--create user in user DB
USE Mydatabase
CREATE USER reader FOR LOGIN reader;
GO
--set the user reader as readonly user
EXEC sp_addrolemember 'db_datareader', 'reader';
For more details, please reference:
Authorizing database access to authenticated users to SQL Database
and Azure Synapse Analytics using logins and user accounts
Hope this helps.
When designing and building databases, one the principal mechanisms for security must be the "least privilege principal". This means that you only give permissions that are absolutely necessary. No application should need to be the database owner in order to operate. This role should be highly restricted to only administration types. Instead, you create a more limited role for the application. It can include access to every single table, all the procedures, but it won't be able to do things like, for example, drop the database.
This is step one to a defense in depth of your system in order to properly and appropriately secure it. It helps with all levels of security issues from simple access to SQL Injection. That's why it's included as part of the vulnerability assessment. It's a real vulnerability.
Yes resolved the issue after creating the least privilege role and assigned to the user. But its leading to different below vulnerable issue's for the newly added user with least privilege role. Any lead will be helpful on this
1.VA2130 Track all users with access to the database
2. VA2109 - Minimal set of principals should be members of fixed low impact database roles
Here on my company we have a SQL Database with several users. However everyone knows the password of 'sa' user.
Now, we have create a Intranet and it is necessary to limit the access to the Intranet database.
I have tryed to create a new owner and remove the permissions from 'sa' user to this database but with no success. What it is more recommended?
Continue this or create a new password for this specific database (is this possible)?
Thanks in advance
I would simply suggest reset the SA account's password. Very very few people should know this password ever. If you need to give specific people this access, then create accounts for them. Applications should almost never have this level of access.
Edit: In MS Sql Server you can have a user on the server level with no access, and then you make that user DBO in a specific database - this enables a user to "admin" a database without being able to mess with the server settings.. This is highly recommended imho.
Here is a detailled guide on how to do it:
First make a login:
http://msdn.microsoft.com/en-us/library/aa337562.aspx
Then give that user access to the DB:
http://msdn.microsoft.com/en-us/library/aa337545.aspx
Don't use SQL Server logins
Use windows logins. When the user should not have access, remove the windows login. You can't make people forget a password but you can revoke windows login access.
I am using EXECUTE AS to allow a least-privilege user to run some SQL stored procedures as a sysadmin. I know that I need TRUSTWORTHY=ON on the source database (the one running the stored procedures) in order to impersonate the sysadmin on other databases on my server. However, even with impersonation granted and TRUSTWORTHY=ON, I still get the following error when trying to touch other databases as the impersonated user:
The server principal [least_privileged user] is not able to access the database XXX under the current security context.
(And yes, I know that module signing is the more secure option. I'm not looking to go that route.)
Can anyone help me?
Use execute as owner.
Make sure the procedure is in the dbo schema.
Make sure the database owner has sysadmin rights on the instance. I
have noticed that SQL logins work better for this purpose than ones
from Windows.
Check trustworthy=on for the database.
This way, you don't need additional impersonation grants, but it is a way less secure solution. It will work, though.
I am trying to give permissions to a user I just created and has a login associated logged into my master.
I was not able to give any permissions since it says you do not have permissions to do this.
I gave myself dbowner rights in the master but still.
Any help?
Might it be that the database I created does not have the schema dbo?
UPDATE:
I thought you said the user you added didn't have any permissions, my bad! Well the answer still might be helpful :-)
I'm not an SQL expert so this may not answer your question, but I had to do something like this today and listing my steps might help.
You can use a graphical tool like Azure User Management Console (AUMC) if you want to add users without having to write a bunch of SQL queries.
Connect to your server, go to Logins and create a new login (if you want to give server access as well), then go to Users, select your database, create a new user, then here you can link the user to the login you just created and give database permissions.
Here is the documentation on granting users/logins permissions:
http://blogs.msdn.com/b/sqlazure/archive/2010/06/21/10028038.aspx
EXEC sp_addrolemember 'db_datareader', 'readonlyuser';
This is my setup:
SQL server 2005
UserA already setup as user on the server but not on databaseA.
GRANT Execute ON [GetOrders] TO [UserA] AS [dbo]
As you can see, i have missed out a step. I haven't added UserA to the database yet. This doesn't fail and lets me grant execute on the object.
I believe in 2000 it would have thrown an error and not allowed me to do this.
Now, I have all these objects with the correct permissions set but the users cannot see the database. To resolve this i have to remove the users from the database, re-add them properly and then give permissions.
Why is this allowed and is there a way to either prevent it or have it create the db login automatically whenever a new user is given object permissions.
thanks.
This is the part throwing you off.
TO [UserA] AS [dbo]
Ditch the "as dbo" part. It's granting the right to the dbo user. Without the "AS [dbo]" part it will throw an error.
It's probably allowed to give DBAs the flexibility to modify the users and permissions when the database is not attached to your production server. I don't believe you have to re-add the users. Take a look at this guy's script: http://www.lazycoder.com/weblog/2007/06/04/re-associate-sql-users-with-logins/