Limited permissions for a SQL Server user - sql-server

I have a .NET application which connects to SQL Server 2008 for storing some data. I use SQL Server authenthication providing an sq username and a password to my end-user in app.config file. If something more needs to be changed I give to the end-user some other credentials.
How can I limit the sql user to only have permission to read/write data and executing existing stored procedures and everything else to be forbidden?
What is the best practice for setting permisions for a sql user that an application is using to connect to a database? Can I prevent somehow the user from logging in Management Studio and mess with my data?
I'm not searching for the perfect 100% reliable solution, but the best existing practice to do this. Thank you very much in advance.
Update: I work on a shared hosting SQL Server environment.

You'll need to create a new SQL user, something like 'LimitedUser'. To do this in SSMS, select the Security Folder of the server you are using, right-click, select New, select Login.
Select your authentication type (SQL server authentication is easily managed), and set the Default database to your database.
You'll need to set Server Roles so this new user only maps to your DB, and in the last page (Status), set Login to false so they cannot use these credentials to login to SSMS and 'mess with your data'.
Click OK, and you're done creating your limited user.
Assign it to your database, and then in SSMS, right-click on your db, select Properties, Permissions.
Select your user or role, and in the permission grid below, switch on only what need to be switched on.

As I see, your question is fully concerned with SQL server security.
You can limit user permissions on server, database or object scope, using GRANT statement, server or database roles. For example, you can assign db_datareader role for user, and then grant EXECUTE permission to this user for some stored procedures (or for entire database).
The current practice in my organization is to create the database roles (e.g. application admin, operator, and so on), adding the appropriate permissions to these roles and then assign these roles to database users.
I'm not completelly sure that you can prevent login into SQL Server Managent studio (SSMS), but SSMS wll not display information that must be invisible for user with user current permissions.

Shared SQL Server hosting where a single instance is shared among multiple customers is not compatible with with typical client-server applications. You are expected to perform all operations through a middle tier server such a WCF Data Service and maintain user accounts within your database in a table with Forms Authentication etc.
For your client-server application you need VPS hosting with your own instance of SQL server where you can create server-level logins. Without creating server-level logins there is no method to secure a client-server application. Any workarounds are just pseudo-security.

Related

SQL Server Username and Password

Using the example below, which is in my App.Config file, are the uid and password values for the SQL Server, or the SQL Server instance, or for the database that is on the SQL Server?
value="server=localhost;database=myDb;uid=myUser;password=myPass;"
Thanks,
ADawn
Sql Server separates the concept of a login from a user. A server instance itself has logins. Individual databases hosted on a server instance have users.
When you want to run a query or otherwise interact with a database, you generally first connect to the server. You supply a username (uid) and password that match a server login. This login in turn maps to a user in one (or more!) databases hosted by that server.
You can see the user mappings by opening Sql Server Management Studio and connecting to your server. In the Object Explorer area expand the Security and then Login folders (just under "Databases"). Double-click a login to open it's Properties window, and find the User Mappings section.
The connection string also includes a database. The purpose here is (again) because a login might map to more than one database. Specifying a database as part of the connection provides context, so you don't need a database name with every table reference in your SQL code.
There's also Windows/Active Directory authentication (Integrated Security). This makes things even messier, because you can set up Active Directory groups (in addition to users) as server logins to manage access for a number of people at once. An Active Directory user can belong to more than one of these groups... and thus map to more than one user in a single database. In my experience, when this happens you tend to get the union of the set of permissions from every database user you could claim, but I haven't studied that situation thoroughly.
server=localhost;
This is the location of the server. You can use the IP address or the name of the computer. Localhost means this code is on the same machine as the SQL server
database=myDb;
This is your database. Such as master (which is a system one)
uid=myUser;
This is a login on the SQL server. Make sure that login has permissions to the database you are trying to access (and subsequent tables). See the picture below, that is a login abc_test.
password=myPass;
The password for the above user
It is possible to have those Logins as Windows Authenticated logins but in my experience in code it's usually SQL Server authentication (mixed mode) logins.
As sniperd said You can create a new login with a new username and password by right clicking on Logins. Or you can use an existing Login name and change its password. Hope this gonna work!

What grants are needed for the SQL Server Telegraf plugin in Azure SQL Database

I'm using the Telegraf input plugin for SQL Server (https://github.com/influxdata/telegraf/tree/master/plugins/inputs/sqlserver) to gather metrics and report to InfluxDB. It works well for SQL Server, but though it supports Azure SQL Database the documentation is a bit sparse.
The database user should be created like this:
CREATE LOGIN [telegraf] WITH PASSWORD = N'password';
GRANT VIEW SERVER STATE TO [telegraf];
GRANT VIEW ANY DEFINITION TO [telegraf];
That works on SQL Server, but in Azure it fails:
Securable class 'server' not supported in this version of SQL Server.
I wonder what I need to grant instead in order to solve this in the best possible way. We have a large number of databases running on the same server in an elastic pool, so if it is possible I would like to use a single user that logs in to the master and collects metrics for all the databases at once (the way it works with SQL Server). If that is impossible I can configure multiple logins and process one database at a time.
Perhaps I can grant VIEW DEFINITION at the database level, but VIEW SERVER STATE does not seem to be supported at all.
So, how should I configure the SQL Database login(s) for Telegraf with the SQL Server plugin to make it work?
EDIT:
Running as the super user for the server works without errors, but only produces metrics for master and tempdb. I need metrics for the many application databases and they are missing. Plus running as the super user is less than ideal.
Running as the super user for the server but connecting to a specific application database (add database in connection string) crashes with a nil pointer dereference and the log complains about VIEW DATABASE STATE permission denied in database master (the super user has access, but apparently not when connecting to a spefic database).
Granting VIEW DATABASE and VIEW DEFINITION to telegraf in an application database and connecting directly to that database as telegraf crashes with a nil pointer dereference and the log says the connection was closed.
EDIT 2:
Created bug report https://github.com/influxdata/telegraf/issues/4222.
EDIT 3:
As of the latest release the plugin works if the server admin account is used, so the issue has been solved. There is still no way to run with a less privileged account in Azure DB.
The answer:
GRANT VIEW SERVER STATE is not supported in Azure SQL Database.
On SQL Database Premium Tiers requires the VIEW DATABASE STATE
permission in the database. Permissions can not be granted in Master,
but the views can be queried in user databases. On SQL Database
Standard and Basic Tiers requires the SQL Database server admin
account due to security requirements following from multi tenancy of
those tiers.
Reason:
SQL Azure SQL is PaaS solution, therefore the most "server" specific features, DMVs, settings are blocked by purpose
References:
Grant View Server State - is it possible for a none SA user to have in Azure SQL?
SQL Azure VIEW DATABASE STATE permission denied in database 'master'
Possible workaround: (which is, anyway does not work in ewramner case)
CREATE LOGIN [telegraf] WITH PASSWORD = N'password';
USE [yourDB]
GRANT VIEW DEFINITION TO [telegraf];
GRANT VIEW DATABASE STATE TO [telegraf];
Therefore, (IMHO), there is no way to make such application working in SQL Azure without changing application code

How can we assign permissions to setup SQL Server Reporting Services

In SQL Server 2012, how can we give a permission to someone to have full control to SSRS and a permission to a specific Db so they can configure and run the SSRS reports and have a full control to backup/restore their Databases but do not have control to other databases on the same SQL Server machine?
Lets say you create a sql user login called sqllogin, Leave this user's Server roles as public.
Under Login Properties section for this user in User Mapping select the one database you want them against (in the list on rightside) and choose the following roles
db_backupoperator
db_datareader
db_datawriter
db_ddladmin
Note: not all options are ticked in image.
This allows user login only to tempdb (for this example) and not the others. They might be able to see other databases but cannot access them in anyway.
More info on roles here
As far as SSRS is concerned, create a datasource mapped to this database with this sqllogin.This is not the same as permission to SSRS but only to the database they get access to.
SSRS permissions are different, I'm pretty sure the sql login cannot be used. This might be of help Authentication SSRS.
But I hope this gets you started.

Securing sql server when impersonating windows users

I have implemented an audit table in my sql server 2008 database using this technique which works exactly as I would want.
However, it relies on SYSTEM_USER to determine the username to write to the audit.
I am connecting to the database through an ASP.NET application, and am impersonating the windows user account in IIS to pass with the database using an integrated security = true connection. To enable the user to access the database I have had to grant them db_datareader and db_datawriter access.
This allows the audit to work as desired, however, I am concerned about security. How can I prevent a user connecting to the database using excel and reading all data?
Basically I want to accomplish 2 things:
Easily log audit records the windows user
Secure data access from anywhere other than my application
From my understanding I can have one or the other, not both.
If I allow access from the windows user I can easily audit, but data is insecure. If I connect with a specific service account the data is more secure, but the audit would not work as required.
Can anyone suggest a way of accomplishing both?

SQL Server: Granting db_datawriter on all databases

I want to manage permissions and access to a SQL Server database server on a development machine. I've created a local windows group (called DBReaderGroup) and assigned various people to it. The group was created as a SQL Server login successfully:
create login [MYMACHINE\DBReaderGroup] from windows
My goal is to grant this group read/write access to all databases (which are constantly being added and dropped). Is it possible to configure the right settings so that SQL Server manages this?
My biggest challenge is that each time a db is created, I have to update the "User Mapping" settings for this group on the new database.
Am I missing something simple?
Add the login to the Model database in the db_datawriter role, and any new database will give that login full write access by default. This won't work, however, if the databases being added are from other sources (ie restored versions).

Resources