1. Intermediate Security Topics in SQL SERver

2. About me e:

3. A Brief overview

4. A Brief Overview
Most security (whether computer or otherwise) is about Authentication and Authorization
Authentication is the secured system verifying a claim of identity
This is ‘who you are’
Authorization is the secured system verifying permissions based on identity
This is ‘what you can do’ based on who you are

5. Authentication
Who are you (really)?

6. Authentication
To start, a user must authenticate to the server (i.e. log in)
How this is done will vary based on what type of Principal attempting to authenticate
A SQL login will provide both username and password
A Windows login will specify neither of the above
Note: a Windows login may not be listed explicitly as having a login, but rather gets their ability to connect via membership in a Windows group.
Other server-level principals exists (i.e. certificate and asymmetric keys), but you cannot log in with them directly

7. Authentication
Once a users is authenticated, the server may assign other identities based on
Windows group membership
Server role membership
Database role membership (database context specific)
Note: both Windows groups and server/database roles can be nested

8. Authentication
DEMO

9. Authorization
What can you do?

10. Authorization
Once the server knows who you are (including any roles/groups you’re in), it can evaluate what you can (or can’t!) do.
Permissions are
Scoped (i.e. within a specific database or at the server-level)
Hierarchical (e.g. a permission applied at the schema-level will factor into the permissions for objects within that schema)
Composable (i.e. all permission that apply to a given object are considered when calculating the effective permission)

11. Authorization Permissions come in two flavors: GRANT and DENY
GRANT says ‘this principal is allowed to do this thing’
DENY says ‘this principal is specifically disallowed from doing this thing’ (as opposed to just not having permission)
DENY overrides GRANT
Either GRANT or DENY can be removed with a REVOKE statement

12. Authorization
What types of permissions are available depend on what type of ‘thing’ the permission is being applied to.
Securable is the term used in the documentation for ‘thing’
For example, the EXECUTE permission makes sense for a stored procedure, but not a table.
What types of permissions are available for a given Securable are in the documentation for the GRANT statement

13. Authorization Permissions can also be implied by other permissions
For example, ownership of an object (which grants CONTROL permission) implies every other permission for that object.
Also listed in the documentation for the GRANT statement for that class of securable.

14. Authorization
DEMO

15. Advanced Topics
As viewed through topics we’ve covered today

16. Ownership Chaining
Many types of objects can reference other database objects
For example, views, functions, stored procedures
When the referenced and referencing object are owned by the same principal, the permissions are not checked on the referenced object
For example, if I own a table in the database and then create a view to reference the table, anyone using the view will only have their permissions checked on the view.
That is, the do not need explicit permission on the underlying table
This is why GRANTing EXECUTE permission on a stored procedure will allow the executing user the ability to run the statements in the procedure without needing explicit permissions on the objects in those statements

17. Ownership Chaining
If the ownership chain is “broken”, permissions revert to object-level. For example
Oliver owns a table
Penelope writes a stored procedure to select from it
Anyone using the procedure will need to have SELECT permission on the table in addition to EXECUTE permission on the procedure
Including Penelope!
But not Oliver (why?)

18. Ownership Chaining
In every environment I’ve been in, the dbo user owns every object
Makes permission chaining simple/non-issue
But…

19. Ownership Chaining
Ownership chaining normally does not evaluate chains across database boundaries
The server-level setting ‘cross db ownership chaining’ relaxes that constraint
Enabling at server says “all databases participate”
Database level setting allow finer granularity
Unfortunately, there’s no way to say “enable chains from certain databases but not others”
Enable (either at server- or database level) with care!

20. Ownership Chaining
DEMO

21. Impersonation
In SQL Server, we have the ability to be somebody else using the EXECUTE AS statement
We can impersonate either a login (i.e. server-level) or a user (i.e. database-level)
Run by itself, the ability to impersonate is governed by the effective IMPERSONATE permission on that principal
Release the impersonation with a REVERT statement
EXECUTE AS can also be specified in the definition of a module (e.g. stored procedures, scalar functions, triggers, etc)
The owner of the module must have IMPERSONATE permission for the principal being impersonated

22. Impersonation
sys.login_token and sys.user_token will be replaced the impersonated context’s until impersonation is REVERTed

23. Module Signing
Since SQL 2005, we’ve had the ability to add cryptographic signatures to modules (anything with a BEGIN…END) with either a certificate or asymmetric key
If we create a principal out of the signing certificate or key, we can grant permissions to the new principal
Those permissions will be appended to the current user token (as opposed to replaced as with impersonation)