Sql Server Security

1,108 views

Published on

Session on SQL Server Security that I delivered at a Usergroup

Published in: Technology
0 Comments
4 Likes
Statistics
Notes
  • Be the first to comment

No Downloads
Views
Total views
1,108
On SlideShare
0
From Embeds
0
Number of Embeds
4
Actions
Shares
0
Downloads
0
Comments
0
Likes
4
Embeds 0
No embeds

No notes for slide
  • Sql Server Security

    1. 1. SQL Server 2005 Security Vinod Kumar M Technology Evangelist Microsoft Corporation www.ExtremeExperts.com
    2. 2. Agenda <ul><li>SQL Server Security Model </li></ul><ul><li>Authentication Architecture </li></ul><ul><li>User-Schema Separation </li></ul><ul><li>Cryptography Support </li></ul><ul><li>Authorization </li></ul><ul><li>Row-Level Security </li></ul><ul><li>Module Execution Context </li></ul><ul><li>Demo </li></ul>
    3. 3. SQL Server Security Model Network connection request/pre-login handshake Login authentication request to SQL Server Switch to a database and authorize access Attempt to perform some action Establish login credentials Connect to the SQL Server computer Verify permissions for all actions within a database Establish a database context
    4. 4. SQL Server Authentication Mechanism SQL Server Client App MDAC Client 1. Connect 2. Establish Socket 6. Acknowledgement 3. Hello 5. Login Packet (Name + Password) 4. Protocol Negotiate Sent in Clear in Microsoft® SQL Server 2000 Can Specify Secure Sockets Layer (SSL) and/or (5+ is encrypted) Mutual Auth (Client cert-store looked) Protocol Changes in SQL 2005 Server authorizes access Policy Changes in SQL 2005
    5. 5. Windows Authentication Mechanism Server authorizes access SQL Server Client App MDAC Client 1. Connect 2. Establish Socket 10. Acknowledgement 3. Hello 4. Protocol Negotiate Local LSA Local LSA DC LSA 5. Initial Security Ctxt 8. Acpt Security Ctxt 6. Cred. Info. Info. 9. Cred. 7. Credential Info. Protocol Changes in SQL 2005 Policy Changes in SQL 2005
    6. 6. Unified Users and Schema – A Problem User Database Object Owned By User 2 Drop user may require application change!! Table View Stored Proc Function Name resolution Eg: Select * from Foo User.foo Dbo.foo
    7. 7. User-Schema Separation – The Solution User Database Object Schema contained in Owned by Owned By User 2 Owned by Default Schema User1 Default Schema S1 User2 User3 Drop user does NOT require application change!! Table View Stored Proc Function Name Resolution Select * from foo S1. foo Dbo.foo
    8. 8. User-Schema Separation <ul><li>Database can contain multiple schemas </li></ul><ul><li>Each schema has an owning principal – user or role </li></ul><ul><li>Each user has a default schema for name resolution </li></ul><ul><li>Most database objects live in schemas </li></ul><ul><li>Object creation inside schema requires CREATE permission and ALTER or CONTROL permission on the schema </li></ul><ul><li>Ownership chaining is still based on owners not schemas </li></ul>Owns Has default schema Owns Owns Schema3 Database Example: creation of table in schema requires CREATE TABLE permission and ownership of schema or ALTER or CONTROL on schema Role1 User1 Approle1 Schema1 Schema2 SP1 Fn1 Tab1
    9. 9. Cryptography Support <ul><li>Overview </li></ul><ul><ul><li>Set of built-ins for encryption , decryption , signing and verification </li></ul></ul><ul><ul><li>Key management infrastructure </li></ul></ul><ul><ul><ul><li>Keys managed by SQL Server </li></ul></ul></ul><ul><ul><ul><li>Keys managed by end-user </li></ul></ul></ul><ul><ul><ul><li>All keys are always stored encrypted </li></ul></ul></ul><ul><ul><li>Key Types Supported </li></ul></ul><ul><ul><ul><li>Symmetric Keys </li></ul></ul></ul><ul><ul><ul><ul><li>RC4, RC2, DES Family, AES Family </li></ul></ul></ul></ul><ul><ul><ul><li>Asymmetric Keys </li></ul></ul></ul><ul><ul><ul><ul><li>Rivest-Shamir-Adelman Encryption (RSA) </li></ul></ul></ul></ul><ul><ul><ul><li>Certificates </li></ul></ul></ul><ul><li>Base set of functionality needed for applications </li></ul><ul><ul><li>Sample scripts for column level encryption </li></ul></ul>
    10. 10. Encryption Hierarchy
    11. 11. Authorization Terminology
    12. 12. Authorization Model - Permissions <ul><li>New permissions for finer grained control </li></ul><ul><li>Permissions associated with semantics </li></ul><ul><ul><li>Not with statements </li></ul></ul><ul><li>Permissions can imply others </li></ul><ul><ul><li>Example: CONTROL </li></ul></ul><ul><ul><ul><li>It implies all other permissions </li></ul></ul></ul><ul><li>Four states of permissions </li></ul><ul><ul><li>Grant (+) </li></ul></ul><ul><ul><li>Deny (-) </li></ul></ul><ul><ul><li>Revoke (take away) </li></ul></ul>- + Deny Deny Revoke [deny] Revoke Grant Grant
    13. 13. Permission Implications Database Endpoint Schema Table Control Control Connect Control Control Alter Alter Control Select Select Alter Select EXECUTE at database Level means you can Execute any procedure CONTROL at Schema Level means you can Do anything in schema
    14. 14. Row-level Security <ul><li>Today we have permissions at table and column level </li></ul><ul><li>SQL 2005: Finer-grained access control at the row level </li></ul>
    15. 15. What if there are multiple predicates? <ul><li>The user query is augmented as follows… </li></ul><ul><ul><li>All GRANTS are Or’d. </li></ul></ul><ul><ul><li>Negatives of all DENY’s are OR’d </li></ul></ul><ul><ul><li>The two sets are AND’ed </li></ul></ul><ul><li>For SELECT </li></ul><ul><ul><li>Only GRANTs and DENY’s of SELECT considered </li></ul></ul><ul><li>For UPDATE </li></ul><ul><ul><li>GRANTSs and DENY’s of UPDATEs and SELECTs considered </li></ul></ul><ul><ul><li>Remember the update restrictions are based on the pre-image…not what is being updated to. </li></ul></ul><ul><li>For DELETE </li></ul><ul><ul><li>GRANTs and DENYs of DELETEs and SELECTs are considered </li></ul></ul>
    16. 16. Module Execution Context <ul><li>Ability to choose execution context of modules </li></ul><ul><ul><li>Module: Stored procs, functions, assemblies </li></ul></ul><ul><li>Permissions checked against current execution context </li></ul><ul><li>Ownership chaining rules still apply </li></ul><ul><li>Option available for dynamic SQL as well </li></ul><ul><ul><li>Alternative to the absence of ownership chaining </li></ul></ul><ul><li>Execution context maintained in the sys.sql_modules catalog view </li></ul>
    17. 17. Execution Context User 3 Select Perms checked for User3 Execute Perms checked for User3 User1.Proc1 User1.T1 Execute Perms checked for User3 NO Perms checked for User3 User2.Proc1 User1.T1 ‘ Execute AS ‘X’ ’ Execute Perms checked for User3 Select Perms checked for ‘X’. Not for user3 SQL 2005 SQL 2000 User 3 User2.Proc1 User1.T1
    18. 18. Impersonation <ul><li>Implicit (four types) </li></ul>Execute as Caller <ul><li>Execute under the caller’s context </li></ul><ul><li>No extra permissions needed </li></ul><ul><li>Default behavior like SQL 2000 </li></ul>Execute as Principal <ul><li>Execute under the specified context </li></ul><ul><li>Impersonate on Principal </li></ul><ul><li>Syntax: execute as ‘domainuser’ </li></ul>Execute as Owner <ul><li>Execute under the module owner’s context </li></ul><ul><li>Impersonate on Owner </li></ul><ul><li>Syntax: execute as owner </li></ul>Execute as Self <ul><li>Run under the context that is creating/modifying the module </li></ul><ul><li>Syntax: execute as self </li></ul>
    19. 19. Demo …
    20. 20. <ul><li>Questions ? </li></ul>

    ×