The permissions that can be granted and to which securables they can be applied are as follows: ■ ■ SELECT Synonyms, Tables and columns, Table-valued functions, Transact-SQL and common
Trang 1Designing a permissions strategy is important when properly securing database objects Considering the hierarchy of securables—a database, a schema, or an
object—you have options of applying permissions by either granting permissions
on the database, on each schema within the database, or on each individual table
or view
The permissions that can be granted and to which securables they can be applied are as follows:
■
■ SELECT Synonyms, Tables and columns, Table-valued functions,
Transact-SQL and common language runtime (CLR), and columns, Views and columns
■
■ VIEW CHANGE TRACKING Tables and Schemas
■
■ UPDATE Synonyms, Tables and columns, Views and columns
■
■ REFERENCES Scalar and aggregate functions (Transact – SQL and
CLR), Service Broker queues, Tables and columns, Table-valued functions (Transact – SQL and CLR), and columns, Views and columns
■
■ INSERT Synonyms, Tables and columns, Views and columns
■
■ DELETE Synonyms, Tables and columns, Views and columns
■
■ EXECUTE Procedures (Transact – SQL and CLR), Scalar and aggregate
functions (Transact – SQL and CLR), Synonyms
■
■ RECEIVE Service Broker queues
■
■ VIEW DEFINITION Procedures (Transact – SQL and CLR), Service
Broker queues, Scalar and aggregate functions (Transact – SQL and CLR), Synonyms, Tables, Table-valued functions (Transact – SQL and CLR), Views
■
■ ALTER Procedures (Transact – SQL and CLR), Scalar and aggregate
functions (Transact SQL and CLR), Service Broker queues, Tables, Table-valued functions (Transact – SQL and CLR), Views
■
■ TAKE OWNERSHIP Procedures (Transact – SQL and CLR), Scalar
and aggregate functions (Transact – SQL and CLR), Synonyms, Tables, Table-valued functions (Transact – SQL and CLR), Views
■
■ CONTROL Procedures (Transact – SQL and CLR), Scalar and aggregate
functions (Transact – SQL and CLR), Service Broker queues, Synonyms, Tables, Table-valued functions (Transact – SQL and CLR), Views
Trang 2cross-Database Ownership chaining
Enabled at the instance level, cross-database ownership enables setting permissions
on one database object such as a view which retrieves data from two or more tables,
or databases in the same instance This approach does provide a slight performance
increase since permission checks are skipped on subsequent objects in the chain;
taking this approach has major implications when managing security Question 14
in the Self Test section of this chapter includes a cross-database ownership chaining
scenario
ExERciSE 4.5
graNtiNg PerMissioNs
You need to add a new login and grant Execute permissions on the
AdventureWorks2008 database.
1 create a new SQL Server login named Test432 and set the default
database to AdventureWorks2008 database.
2 create a new database user in the AdventureWorks2008
data-base, mapping it to the SQL Server login Test432 Do not give the
user any permissions.
3 Execute the following code:
GRANT EXECUTE ON DATABASE::AdventureWorks2008 TO Test432
4 Once you see, “command(s) completed successfully”, user Test432
will have to execute permissions on all the objects in the
AdventureWorks2008 database.
5 To test what you’ve done, log in to SQL as Test432 and run the
following code:
exec dbo.uspGetEmployeeManagers 2
If you do not get an error, your grant worked properly
Trang 3Object Permissions
Modules can be marked with an execution context This enables the code to be run under a specific security context other than whom or what may be calling it
As long as the appropriate permissions exist for context in which the module is run, users only need to be granted permission to the module Granting explicit object permissions to the module reference objects for the module’s users is not necessary
The following arguments are available when specifying an Execution Context:
■
■ CALLER Statements inside the module are executed in the context of
who called the module Appropriate permissions must be applied to the module being called as well as all objects referenced by the module
■
■ SELF Equivalent to EXECUTE AS user_name, the specified user is the
person creating or altering the module
Head of the Class…
The Correct Match of Permissions
It can seem like every request brings a new challenge for determining the best match for permissions when adding a new user to a database When business areas consolidate or the responsibilities or business areas span across multiple business areas such as accounting, where they are often involved in supporting every other business area in an organization,
it is necessary to construct a list of permissions requirements before just dropping the user into a role or granting a permission that looks like it might work.
You should always be able to justify the choice that you have made You may need to explain in significant detail what permissions a user or users have been granted Taking the time to gain a thorough under-standing of the SQL Server security hierarchy will greatly help you not only make the best decisions when designing access, you will have a more secure instance and be able to speak with confidence when answering questions in regard to permissions.
Trang 4■ OWNER The module is executed in the context of the current module
owner or if an owner is not specified on the module then the owner of
the schema of the module is used
■
■ ‘user_name’ The module is executed in the context of the user specified
in user_name
■
■ ‘login_name’ The module is executed in the context of the SQL Server
login specified in login_name
Be sure to understand the purpose for each Execution context and
what permissions are necessary for the objects in the chain.
Log-in Permissions (As Related to Roles)
Logins can be added to server-level roles which are used to grant server-wide
privileges to a user added to any of the fixed server-level roles It is important to
remember to make sure that a user is not being granted more permissions then they need The server-level roles generally have the ability to perform tasks beyond the
scope of users other than a DBA or server administrator
ExERciSE 4.6
aDD a sQL server logiN to a server-level role
You will add a SQL Server login to the db_creator server-level role.
1 Logged in as sysadmin, Execute the following code (any SQL
Server login can be specified that does not already exist in the
db_creator role):
exec sp_addsrvrolemember @loginame= 'test432', @rolename =
'dbcreator'
2 Verify that the log-in name you specified is now shown as a
member of the db_creator server-level role.
Trang 5Available in SQL Server 2008 Enterprise, automatic auditing can be set up by using SQL Server Audit The Audit object can capture activity in the database server and save it to a log Audit information can be stored in a File, Windows Application Log,
or Windows Security Log
In order to create an Audit object you need to first use the CREATE SERVER AUDIT statement The following is an example of creating a server audit that is saved to a file:
CREATE SERVER AUDIT HIPAA_File_Audit
TO FILE ( FILEPATH='\\SQLPROD_1\Audit\' );
The resulting filename generated takes the form of: “AuditName_AuditGUID_ nn_TS.sqlaudit.”
After you have created the Audit object, events can be added to the server audit that you created by creating a server audit specification The syntax for that looks like the following:
CREATE SERVER AUDIT SPECIFICATION Failed_Login_Spec
FOR SERVER AUDIT HIPAA_File_Audit
ADD (FAILED_LOGIN_GROUP);
Database Audits can also be created to track and CREATE, ALTER, or DROP actions in the database or any INSERT, UPDATE, or DELETE activities performed
on database objects
An example of creating a database audit specification looks like the following:
CREATE DATABASE AUDIT SPECIFICATION Sales_Audit_Spec
FOR SERVER AUDIT HIPAA_AppLog_Audit
ADD (DATABASE_OBJECT_CHANGE_GROUP),
ADD(INSERT, UPDATE, DELETE
ON Schema:: Sales
BY SalesUser, SalesAdmin);
Be sure to understand the difference between server-level and database-level audits and your options for storing the audit activity.