I was just wondering if there are any access methods or rules to prevent people from accessing a database? I'm pretty new to sql so if so, how would you implement a method or rule to a database? Is it through properties of the database, or does it have to be written in SQL script somewhere?
I am using Microsoft SQL Server 2008.
Any help appreciated, thanks in advance.
At a high level:
To allow a user access you need to have a login present at server level (the level higher than your DB's). There will be a 'Security' node at the server level where you can 'add login'. Depending on whether you're using windows user accounts (integrated security) or sql server logins the precise format of the logins will vary, but the user added will want to match the format of the accounts you are using.
Once you have granted a user access to the server in terms of a server login, you can then grant permissions at a database level. There will also be a 'Security' node at database level where you can add a new login at database level.
The database level login needs to match or be mapped to a login at server level.
At database level you can grant/deny all kinds of permissions, but it would be common to grant roles to a user, SQL includes built in roles such as 'datareader'/'datawriter' which are often used for 'generic access'
The image Diego posted illustrates in the GUI where to find some of these options, but the permutations are lengthy and it would be hard to explain any more without knowing some specifics about what you are trying to do.
Read about Logins and Users.
Logins protect you at a server level and Users at a database level. A user usually inherits a login's information.
you can see them on SSMS:
there is no point on writing too much as you can simple google it and find tons of explanations
Related
I would like to create a user account in SQL Server 2012 with limited access, i.e., he should be only able to run queries and view data and nothing else. No backups, restores, user modifications should be allowed.
I tried looking at the built in server roles, but could not really understand it too well. The Server consists of some 7-8 different databases and we would like this user to have only querying access across all databases and nothing more. Would be great if somebody could guide me as to how to implement it.
Regards
Saurabh
Simple create role and grant access to needed objects with command GRANT. Example:
GRANT SELECT ON TABLE1 TO ROLE_ONLY_VIEW_FOR_EXAMPLE
Then you can assign this role to any user you want.
So I wanted to know if there is an acceptable method to Allow SQL Injection.
Example:
Limit permissions on the table(s)/database(s)
Why you ask?
My employer wanted to devise a way to test the skills of applicants, one suggestion was to allow resume submissions via SQL Injection.
Any thoughts? suggestions?
You could use roles. Create a role for the web application (or whatever) that is used to connect to the database. Limit this role to only permit INSERT and access to necessary tables for applying. Applicants with access to your database through the application could then only use SQL injections to add their resume.
It may be possible for someone more talented in SQL to use injections in a way that increases the role's permission. But I think if the role had limited access to only specific tables and didn't have CREATE or GRANT privileges, the user wouldn't be able to create new roles.
Here is some information on roles to get you started:
Adding Roles to MySQL with MySQL Workbench
Creating Roles in PostgreSQL
GRANT command - used to add privileges to users on table, database, etc. This page is for PostgreSQL, but MySQL is very similar (see this SO answer)
Given that the reason behind this is to test people's ability, create a database with data you can afford to lose. Set up a form that posts to a coldfusion or php or java or .net or some other type of page which connects to that database.
On the form, put a textarea and submit button. On the form target page, log what they put in the textarea. Compare the log to the database to see how it turned out.
Then test to your heart's delight.
I use C# Asp.net and SQl 2008 R2
I'm pretty new to DB so I need some guide line.
I create a User A with Role/Permission Administrator to create my DB using MS Management Studio.
Now I need to set-up my website to READ/UPDATE/DELETE Rows in my Tables, this user will be pointed in the Connection String.
My questions:
in the connection String shall I user A (Role Admin)?
or should I crete a new User and giving role Data Reader and Data write?
I need my code able work with the content of my table but do not modifying the schema.
Please let me know. Many Thanks
You should create a new user that has the minimum permissions possible.
This way, if anyone takes over the website, they are limited to doing only what this user can do and can't do the other things the admin user can.
If you use the admin user, there is a risk that a malicious user will be able to change the schema (or even drop the database) using SQL injection or other techniques to inject their code into your server.
Additionally, if you have any code that would change the schema, which might be called (perhaps as an oversight or coding error), the damage is limited to what the low privileged user can do.
This is part of defense in depth.
I'm quite new to Microsoft SQL Server. I have some experience with MySQL, and there you have a user with privileges, if I understand things right; these privileges decide which databases you have access to on the MySQL server.
However now I am in the situation where I have to restore a database on my SQL Server 2005 Express, and this database has it's own users and user password. So if I want to make these users accessible from the outside (so that they can connect to my server), how would I go about that?
To illustrate clearer; say there are two login accounts on the database server "Mike" and "John", and on the database "Animals" there are two users; "Chris" and "Jeff".
I need Jeff to be able to sign in to get access to the database. Is there a good way to make this happen without creating new users/logins? And if not, what is the best/most common solution?
I would really appreciate any helpful input on this!
One server-level object (login) is mapped to multiple database-level objects (users).
A login cannot be mapped to more than one user within a database, but can be mapped to at most one user in each database.
Therefore, you need to create new logins for those users, but map them to existing users. This is done with ALTER USER command. Or, if you don't have any use for the Mike and John logins apart from mapping them to those existing users, you can do so, too.
Any user needing to access a database needs to either have their own login, or you can create a login for a Windows security group and grant access that way to a whole set of users. Then if you need to give access to more users in the future you can just add them to the windows security group.
I have recently been running into many different areas of SQL Server that I normally don't mess with. One of them that has me confused is the area of Logins and Users. Seems like it should be a pretty simple topic...
It appears that each login can only have 1 user and each user can only have 1 login.
A login can be associated to multiple tables thus associating that user to many tables.
So my question is why even have a login and a user? they seem to be pretty much one in the same. What are the differences, or what is it that I seem to be missing?
A "Login" grants the principal entry into the SERVER.
A "User" grants a login entry into a single DATABASE.
One "Login" can be associated with many users (one per database).
Each of the above objects can have permissions granted to it at its own level. See the following articles for an explanation of each
Principals
Database Users
One reason to have both is so that authentication can be done by the database server, but authorization can be scoped to the database. That way, if you move your database to another server, you can always remap the user-login relationship on the database server, but your database doesn't have to change.
I think there is a really good MSDN blog post about this topic by Laurentiu Cristofor:
The first important thing that needs to be understood about SQL Server
security is that there are two security realms involved - the server
and the database. The server realm encompasses multiple database
realms. All work is done in the context of some database, but to get
to do the work, one needs to first have access to the server and then
to have access to the database.
Access to the server is granted via logins. There are two main
categories of logins: SQL Server authenticated logins and Windows
authenticated logins. I will usually refer to these using the shorter
names of SQL logins and Windows logins. Windows authenticated logins
can either be logins mapped to Windows users or logins mapped to
Windows groups. So, to be able to connect to the server, one must have
access via one of these types or logins - logins provide access to the
server realm.
But logins are not enough, because work is usually done in a database
and databases are separate realms. Access to databases is granted via
users.
Users are mapped to logins and the mapping is expressed by the SID
property of logins and users. A login maps to a user in a database if
their SID values are identical. Depending on the type of login, we can
therefore have a categorization of users that mimics the above
categorization for logins; so, we have SQL users and Windows users and
the latter category consists of users mapped to Windows user logins
and of users mapped to Windows group logins.
Let's take a step back for a quick overview: a login provides access
to the server and to further get access to a database, a user mapped
to the login must exist in the database.
that's the link to the full post.
In Short,
Logins will have the access of the server.
and
Users will have the access of the database.
I think this is a very useful question with good answer. Just to add my two cents from the MSDN Create a Login page:
A login is a security principal, or an entity that can be authenticated by a secure system. Users need a login to connect to SQL Server. You can create a login based on a Windows principal (such as a domain user or a Windows domain group) or you can create a login that is not based on a Windows principal (such as an SQL Server login).
Note:
To use SQL Server Authentication, the Database Engine must use mixed mode authentication. For more information, see Choose an Authentication Mode.
As a security principal, permissions can be granted to logins. The scope of a login is the whole Database Engine. To connect to a specific database on the instance of SQL Server, a login must be mapped to a database user. Permissions inside the database are granted and denied to the database user, not the login. Permissions that have the scope of the whole instance of SQL Server (for example, the CREATE ENDPOINT permission) can be granted to a login.
Graph on logins / users from MS sql-docs