I am new to sql server so need help with this... Though I have added a user and under user mapping I have only one database that user can access, from within my application I can see he can access :master,msdb and tempdb (as well as the database I have granted him the access to).Not only from my application but also using managment studio as well. How comes he can access these first three options (databases) ? How can I have him access only designated database and nothing else?
Logins with CONNECT privilege can also access databases with the guest user enabled. The master and tempdb system databases require the guest user to be enabled for SQL Server to be functional. Enabling the guest user in msdb is optional, but some applications may not operate correctly without it enabled.
Note that access to these system databases is not normally a security concern due to meta-data visibility restrictions.
Related
How do I set up a database so that one does not have access to it? Even with installing SQL Server Management Studio on local machine.
In SQL Server with Windows user or sa can access all databases. How do you limit the access DB of the users?
For assuming that SQL Server is installed on the local machine, not on the server
You can try Single User Mode.
From the linked MSDN article:
Single-user mode specifies that only one user at a time can access the database and is generally used for maintenance actions.
Edit: You edited your question. Now it sounds more like you're asking about Security instead of how to limit the database to one user.
You can edit a user's security in SQL Server Management Studio by drilling down into Security > Logins. There you will see all logins to your instance. You can right click these entries and select Properties to made updates. The easiest way to completely bar a user from accessing any of the databases on the server is by selecting "Disabled" from the "Status" tab.
Well, if you really want to limit this to just one user, there is a simple way (but a bit risky).
Your Windows user is included in the group BuiltinAdministrators. If you really want to remove your Windows user, rerun the installation process and during the setup just change the users in those group.
But beware, you should provide another user, which has access to your database otherwise you end up with a database server without access to it.
Ater that, setup a database login and grant him access to the database you desire.
In the end, you can disable the sa login. This will prevent access with the sa account. But you should have a user which can manage logins and more. Otherwise you have no chance to recreate the password or any other administrative tasks.
I just enabled remote connections on my SQL Server Express 2012 installation. Now I am a little bit worried about the server security because allowing connections to everybody sounds like a big security hole for me.
Is it possible to tell the SQL Server to disconnect if the user is trying to authenticate with a user which is not on my "allow" list? If so, I could add my monitoring user to this list and don't have to worry that my administration accounts are accessible.
First of all, this is probably a question that should be asked in the DBA site. Anyway, you can set up the security of the server so that only certain users are allowed to login.
When you set up the server, you add Logins to the Server Level and then Users at the database level. Only the users that are setup can, obviously, use a particular database. You can place users into roles, so, for example, they will have read-only access to a database. You can control, down to the object level, who has access to what.
There is a good article on what SQL Server security is about here
Having said that, sometimes, after, you have setup your security, you need to disallow certain users to not be allowed to Logon. Perhaps you are doing some major upgrade to the database. One option in this case is to create a Logon trigger.
A Logon Trigger will fire every time a user Logs in. You could create a table of "allowed" users and, in the trigger, if they are not in the table you ROLLBACK, effectively disallowing the Logon.
Here is information about creating a Logon trigger
You should be able to set up the db server to only accept connections from certain IP addresses, rather than to all of them. I'm unsure of the T-SQL syntax, but someone will surely chime in with the correct one.
If you really mean business, that being said, you'll want to authenticate clients using certificates that you give them. See this and the various articles it links to:
https://security.stackexchange.com/questions/14589/advantages-of-client-certificates-for-client-authentication
Being able to connect remotely to a SQL Server instance does not mean that they can Login to it. If they are not authorized properly, they should still get kicked-off by the SQL Server Login Authentication sequence.
This is silent/invisible for "Trusted Logins" (where the authorization comes from their Windows Login/Domain Account), but it still happens.
If you look under the "Security" folder of your Server (in SSMS), you will see the list of authorized Logins to you SQL Server. By adding or removing these you can control who can actually create a session on your SQL Server.
We have an application that uses Windows authentication to authenticate users with the database, and the SQL Server user accounts need to have certain read/write access to database tables.
The trouble is that the users can then install SQL Server Management Studio and potentially use the database in ways it's not supposed to be used, which isn't what I want.
Everything that I have read says that using integrated authentication is more secure but at the moment, any user can use Management Studio or Access/Excel to just connect to the database.
I have read question SQL Server Authentication or Integrated Security?, which suggests some workarounds, but I don't really have the option of changing the app as drastically as re-factoring all of the stored procedures etc. so I was hoping there might be another option?
Thank you,
NIco
Everything that I have read says that
using integrated authentication is
more secure
--> It's more secure in a way because it's more difficult to get the password.
If you use SQL Server authentication, the connection string contains user and password. If you know where the connection string is (often in a config file), you can open it and see user and password.
On the other hand, if you use Windows authentication, the connection string just says "Integrated Security=True" and you connect to the server with your Windows account, with the actual password buried somewhere deep in Windows' guts and more difficult to retrieve.
Of course, the big downside of Windows authentication is that if your users need write permissions on a certain table for your application, this means that they can write to the same table with ANY other application as well.
There are some workarounds, but none of them is THE silver bullet:
If your app only needs certain tables of the DB, you can just give permissions on these. So at least, the users can't do stuff in all the other tables
If the users are not allowed to access any tables at all from outside your application, there are unfortunately only two things you can do:
Change your app to SQL authentication and remove all permissions for Windows users
(you can also use a proxy service like Will Hughes suggested, but the effect is the same when the app accesses the DB directly...the point is that your users' Windows accounts don't have any permissions anymore!)
Create views and stored procedures (if they don't already exist anyway) for the stuff your app can do with the database. Give the users permissions to use these, and remove the permissions to the real tables.
--> the users can access the views and SPs directly with other tools (even if they don't have any permissions on the underlying tables...permissions on the views and SPs are enough), but they can't do anything that they can't do in your app as well.
If you don't want users to have access to your database, don't grant them access.
If you need to control what they can do - then you should do your access control in a webservice (or some other form of proxy service), which will then execute approved queries, return data, etc.
Is there a way to secure a sql server database which is accessed by a fat client? Meaning: The application communicates directly with the database as it places sql statements itself. That means, the connection string has to be somewhere on the client. Using this connection string (either with winauth or sql server authentication) any user can access the db using some management studio or command line and place different statements to the db than the GUI would let him.
What to do about that? I cannot place another layer between the client and the database as this architecture is fix.
In all security models, including Windows and SQL Authentication, access rights are granted to an user (an identity), not to an application. therefore, any access right needed by the application must be granted to the user running the application. When Windows authentication is used this means that the same user can leverage all the privileges needed by the application himself, from an SSMS query. This is a fundamental rule any administrator must understand. From a security point of view (meaning things like CC compliance and such) this is a fact and any attempt to circumvent it is doomed.
But from a practical point of view, there are certain measures that can be deployed. The most commonly used one is to use a logon trigger that validates the APP_NAME() and allows access for SSMS only from a well defined set of client workstations, and for a well defined set of users.
CREATE TRIGGER reject_SSMS
ON ALL SERVER WITH EXECUTE AS '...'
FOR LOGON
AS
BEGIN
IF (APP_NAME() = 'Microsoft SQL Server Management Studio'
OR APP_NAME() = 'Microsoft SQL Server Management Studio - Query')
AND (ORIGINAL_LOGIN() NOT IN (...)
OR HOST_NAME() NOT IN (...))
ROLLBACK;
END;
What is important to understand that such mechanisms are NOT security features, as they can be easily circumvented by a malevolent user. They are more like door locks: they don't keep thieves out, they keep honest users honest.
That is what SQL Server permissions are for.
You can do things like give permissions to a user on a View or Stored Procedure without giving the user permissions to the underlying tables.
You might want to look into Application Roles
http://msdn.microsoft.com/en-us/library/ms190998.aspx
http://www.sqlservercentral.com/articles/Security/sqlserversecurityprosandconsofapplicationroles/1116/
First and foremost the whole point of a SQL Injection vulnerability is that the attacker is able to manipulate queries. This purposed protocol is an even worse vulnerability. But not only that this is also a clear violation of CWE-602: Client-Side Enforcement of Server-Side Security and CWE-603: Use of Client-Side Authentication.
In order to make this secure you must do the following:
Each user must also have their own locked down database. As in they only have select/update/delete/insert and no other privileges (especially not xp_cmdshell()!!!!). You cannot allow users share a database, or an attacker will be able to view other users information. An attacker will always be able to obtain the username/password for the sql server and be able to connect directly with his own client. Its hard to think of this relationship as being secure, in almost all cases this is massive vulnerability.
In all reality this is a very serious architectural flaw and you must build a server side component that builds quires for the client. This is usually done with SOAP (wcf for ms platforms).
Background
I am in the process of creating an application (referred to as MyApp) which must read data out from a SQL Server database handled by Navision. Navision users should to be able to use my application, without modifying permissions in the database.
Navision's handling of permissions seems to be on the application layer. It performs the checking of permissions without storing them in the database.
Problem
Navision overwrites users, permissions, and other related objects in the database when synchronizing with the database, so the normal approach of creating a DB user and just using that won't work.
Possible Solution
What I think would be the most appropriate solution is to create a MyApp role in Active-Directory, which grants the necessary permissions on the DB, and add this role to all users.
I do not know how to do this, or even if it's possible. Other solutions, or proposals, are welcome, but please only suggest solutions with can be managed from within ActiveDirectory or Navision.
The server is an SQL Server 2008 server running Navison 5, and the client is Navision 6. I'm using Active Directory for Windows Server 2K8.
EDIT:
My app is a crate creating and designing application. It needs to read out the customers' names and IDs, and a few items in the items table, and that is why I need this functionality
If you use the enhanced security model in NAV, user permissions are synchronized to SQL Server. However, these SQL permissions are mapped to an app role in SQL Server, rather than the user's login. If you use the standard security model, all users map to a single SQL app role which is a super user (less secure).
If you want to access the data in SQL Server using the NAV security model (i.e. through the SQL App roles NAV creates), you should use the CFront API (installed via the SDK option). If you are using NAV 2009 web services are also an option.
If you want to access SQL Server directly, then you will have to manage the permissions yourself using SQL Server. If you create a SQL script to grant permission it is easy to restore anything which NAV might delete during Synchronize Logins.
You can't grant SQL permission from Active Directory exactly as you described. Instead you must map Active Directory groups to either SQL Server logins or NAV Windows Logins (depending on whether you decide to access SQL directly or go through a supported NAV API). Note: the permissions associated with the role are managed in SQL or NAV respectively; not in AD.
From an administration perspective, you can simply add and remove users from this Active Directory group. If you use the NAV enhanced security model each user in the AD group must also have an entry in Windows Logins, and whenever you make changes you must Synchronize Logins. This slight inconvenience is a hangover from the native database.
In general, skipping the NAV layer and reading/writing directly to the DB is not recommended at all as you're bypassing all of NAVs business logic which is stored in the table and report objects in NAV.
What does your app intend to do (broad strokes if you can't get specific) and would using a NAV add-in or dataport be feasible?