1. Introduction to SQL 2005 Security Nick Ward SQL Server Specialist nickward@microsoft.com Nick Ward SQL Server Specialist nickward@microsoft.com

2. Database Security Prevent SQL injection attacks Encrypt data in the database Secure data over the network Secure database connection strings Handle data access exceptions

3. SQL Server 2005 Overview

4. SQL Server 2005 Security Initiatives Trustworthy Computing Initiative Security, privacy, reliability and business practices http://www.microsoft.com/mscorp/twc/default.mspx SD3+C Secure by design Secure by default Secure in deployment Communications

5. Reduction in Surface Area Secure by Default More optional installation options Default: Demonstration databases not installed Default: CLR disabled Default: HTTP endpoint disabled Minimized Attack surface: Features require explicit configuration Surface Area Configuration Tool

6. SQL Server 2005 Security Surface Area Configuration Tool Nick Ward SQL Server Technology Specialist Microsoft Nick Ward SQL Server Technology Specialist Microsoft

7. The Least Privilege Principal Granular permissions Grant/revoke/deny Hierarchical permissions Security execution context EXECUTE AS Functions, procedures, views and triggers DDL Triggers

8. Security: Execution Context User 3 Select Perms checked for User3 Execute Perms checked for User3 User2.Proc1 User1.T1 Execute Perms checked for User3 Select Perms checked for User3 No permission – User1.Proc1 fails User 3 User2.Proc1 User1.T1 ‘Execute AS ‘X’ ’ Execute Perms checked for User3 Select Perms checked for ‘X’. Not for user3 User2.Proc1User1.T1

9. Security: Execution Context Execute AS CALLER Default – same as SQL Server 2000 behavior Execute AS SELF Last person to create or alter the module Execute AS OWNER Execute as current owner of the module Execute AS “UserName” Execute AS “LoginName” Only for DDL triggers with server-wide execution

10. SQL Server 2005 Security EXECUTE AS ‘x’ Nick Ward SQL Server Technology Specialist Microsoft Nick Ward SQL Server Technology Specialist Microsoft

11. DDL Triggers Triggers fire when Data Definition Language (DDL) is executed Used to: Prevent DDL changes to your schema Cause something to occur when schema changes To record changes or events in the database schema Fire after the statement Can roll back the statement’s effect Can run managed code

12. SQL Server 2005 Security DDL Triggers Nick Ward SQL Server Technology Specialist Microsoft Nick Ward SQL Server Technology Specialist Microsoft

13. Secure in Deployment Microsoft Update services integration Automatic or manual Systems Management Server (SMS) integration Deployment security content: “Security Considerations for SQL Server” http://msdn2.microsoft.com/en-us/library/ms161948 Windows server Network Windows service accounts Surface Area All SQL Server components

14. Authorization Enhancements Already discussed Granular permission control Module execution context Still to come… User schema separation Metadata security Encryption enhancements

15. New DDL for user and schemas CREATE/ALTER/DROP for USER, ROLE, and SCHEMA Dropping user does not require application rewrite Security Schema v object permission Default schema Schema Security: User-Schema Separation Table Function View Stored Procedure Bill Owned ByContained InOwned By Mary Server.Database.Owner.ObjectServer.Database.Schema.Object

16. SQL Server 2005 Security User-Schema Separation Nick Ward SQL Server Technology Specialist Microsoft Nick Ward SQL Server Technology Specialist Microsoft

17. Security: Certificates Encryption enhancements Encryption uses symmetric keys, asymmetric keys and certificates SQL Server 2005 can generate certificates for encryption RC4, RSA, Triple-DES and AES encryption supported Encryption can be used with any level of SQL Server 2005 securable Key Management

18. Security Hierarchy

19. SQL Server 2005 Security Data Encryption Nick Ward SQL Server Technology Specialist Microsoft Nick Ward SQL Server Technology Specialist Microsoft

20. Metadata No visibility without permission “VIEW DEFINITION” permission

21. SQL Injection Consider the following: var Shipcity; ShipCity = Request.form ("ShipCity"); var sql = "select * from OrdersTable where ShipCity = '" + ShipCity + "'"; Enter “Melbourne”: select * from OrdersTable where ShipCity = ‘Melbourne' Enter “Melbourne'; drop table OrdersTable—” select * from OrdersTable where ShipCity = ‘Melbourne';drop table OrdersTable--'

22. SQL Injection – What to do? Validate all input: length, type, ranges, valid values etc. Reject control characters: ; ‘ -- /* */ xp_ Never build T-SQL statements from user input – beware string concatenation Use stored procedures Visual Studio Team System 2005 Type-safe SQL parameters SqlDataAdapter myCommand = new SqlDataAdapter("AuthorLogin", conn); myCommand.SelectCommand.CommandType = CommandType.StoredProcedure; SqlParameter parm = myCommand.SelectCommand.Parameters.Add("@au_id", SqlDbType.VarChar, 11); parm.Value = Login.Text;

24. © 2003-2005 Microsoft Corporation. All rights reserved. This presentation is for informational purposes only. Microsoft makes no warranties, express or implied, in this summary.