Professional Documents
Culture Documents
Basic concepts of SQL Server security Authentication modes Logins Database components
Every user that connects to SQL Server must have a valid login id, and that login id must be registered with SQL Server.
SQL server security starts with login, the server and its databases
Databases
Logins
SQL Server Windows NT NT Groups NT Users
Logins
SQL Server logins consist of a login name and password that are stored in SQL Server. Windows NT logins are Windows NT user names or groups that are registered by the system administrator within SQL Server. With Windows 95 and 98, all you can use are SQL Server logins.
Logins can have two levels of access, the server level and the database level
Server Roles
Permissions
Database Objects
Note
The upshot is that to gain access to a database, every login must have some explicit or implicit mapping to a database user application role in that database.
Implementing security
When you log into a fresh SQL Server installation, SQL Server security can seem invisible. When you use the sa login, or you use a trusted connection and your NT login belongs to that machine's NT administrators group, you can immediately access all the databases and their objects (tables, views, stored procedures, and so forth).
Implementing security
BECAUSE every database object in all the standard databases is owned by a database user, present in each database, called dbo (abbreviation for database owner), and those privileged logins automatically map to the dbo of every database.
Implementing security
BECAUSE every database object in all the standard databases is owned by a database user, present in each database, called dbo (abbreviation for database owner), and those privileged logins automatically map to the dbo of every database.
Note
Any login with system administrator rights can immediately see all the database objects of every database in the server. Therefore, implementing SQL Server security consists of using logins other than sa or an NT login with local Administrator rights.
Warning
If you only use the sa login or an NT login that belongs to the local machine's Administrators group, you are bypassing SQL Server security.
Authentication Modes
SQL Server really has three total security authentication modes:
SQL Server authentication only (Windows 9x ) "standard security SQL Server and Windows NT authentication "mixed" security Windows NT authentication only "integrated" security
SA login
Every SQL Server login requires a password. In the case of sa, it is initially set to blank (no password at all). Dont leave it blank, change it for security reasons.
Server Roles
In prior releases of SQL Server, you would have to log into SQL Server as sa in order to do any kind of maintenance activity. With SQL Server 7, the sa functionality has been subdivided into a set of server roles. These server roles stand between the logins and the server.
Server Roles
Logins
SQL Server Windows NT NT Groups NT Users
Warning
The Administrators group of the server computer automatically has a login into the server and belongs to the sysadmin server role. So if an NT user belongs to the administrators group of the local machine, that user can immediately log into the SQL Server and has sysadmin (and therfore sa) privileges. You can deny access to the BUILTIN\Administrators group to deny such users access to the server.
Server Roles
Logins
SQL Server Windows NT NT Groups NT Users
Database Objects
Database Access
SQL Server data is contained in databases. Just connecting to SQL Server will not by itself allow access to the server's data. Consequently, there must be some means of mapping authenticated logins to data in databases. The way SQL Server accomplishes this is by three components inside a database: database objects, database users, and database roles.
Server Roles
Logins
SQL Server Windows NT NT Groups NT Users
Database Objects
Database Objects
The database objects are the tables, indexes, triggers, defaults, constraints, riles, views, and stored procedures in the database.
Database Users
Database users are the names of the owners and users of the database objects.
Database Roles
Database roles are groupings of users. Both database users and roles can be granted and denied permissions to the database objects.
Database Access
Every database object is owned by exactly one database user. The only way you can access a database object is by either being the object's owner or having access to the object granted to you by the object's owner. Every database has at least one database user the dbo. The dbo owns all the system tables in a database, as well as all objects created by the sa login or sysadmin role.
Note
When you log in as sa or have a login that gives you the sysadmin role, you can automatically see all the objects in a database that are owned by dbo. These include all the system databases such as master, msdb, model, and tempdb, as well as the entire pubs databse. Then all objects you create under such logins become owned by dbo.
Note
The key concept here is that without the mapping of a login to a database user, no login can access a database's data. You can map a login to only one database user per database, but you can map that login to more than one database at a time.
Database Roles
Database roles are ways of grouping users together so that they inherit the permissions of the roles, so that you do not have to explicitly grant permissions for each database user.
Database roles
Fixed standard Server Subdivisions of dbo rights supplied by SQL Server Custom standard Roles created by the database administrator Application Roles for applications that bypass database users
The database user, dbo, is automatically a member of the db_owner role. You cannot add new fixed database role.
Application roles
Application roles are a special kind of role that can be used to switch the permissions that a login would normally have, based on a password sent to the system. In this way, someone running an application could get permissions to database objects that they would never get using their own login.
Application roles
If the users log in without the application, you might deny them access to the database objects. However, when they run the application, the application can assume the application role that does give access to the database objects.
Application roles
Application can use the application role to gain new security without logging off and logging into SQL Server.
Permissions
After a database has database users and roles, you can grant permissions to database objects through them.
You can set permissions to database objects for both database users and database roles
Server Roles
Logins
SQL Server Windows NT NT Groups NT Users
Database Objects
Permissions
Every object in a database has an owner, and an object owner is always a database user. Database objects include tables, views, and stored procedures etc. Normally the creator of the object is its owner. The owner of an object can grant and deny permissions to the object.
Note
The full name of every database object includes the database name, the owner name (a database user), and the object name. Two different users can each create a table or object with the same name in a single database
Assigning permissions
Any login with the sysadmin or securityadmin server roles (therefore including the sa login) can assign permissions to database users and roles, Permissions are assigned with the GRANT, REOVKE , and DENY commands , and the content of the permission is chosen in the body of the command.
GRANT
Applies to the database user or a role. If the role has the GRANT permission, and the permission is not otherwise denied, every database user will inherit the GRANT permission from the role.
REVOKE
When you REVOKE a permission, it removes the prior GRANT permission, if there was one, but does not explicitly prevent a database user from inheriting a GRANT from a database role.
DENY
The DENY action takes precedence over the GRANT action. When you deny a permission to a database user or role, the permission is explicitly removed. Further the deny status overrides all other GRANT permissions in the various roles to which a database user may belong.
Database permissions
You can grant all of the following CREATE or BACKUP statement or a subset of them, to a user or role. CREATE BACKUP
DATABASE DEFAULT PROCEDURE RULE TABLE VIEW DATABASE LOG
Object-level permissions
Table or view
SELECT INSERT UPDATE DELETE DRI
Stored procedure
EXECUTE
Security functions
A full set of security functions exist to find out the login name, user name, and role memberships for each login. You can use these functions to add a further level of security.
Security functions
Some useful security functions : Is_member() suser_sname() user() is_srvrolemember()