Being More Secure SQL Server 2005 Don Vilen Program Manager, SQL Server Microsoft Corporation

Agenda  SQL Server Security Overview  Background  Principals, Securables, Permissions  Authentication  Authorization  Auditing  Encryption  Surface Area Reduction  Best practices

Some Relevant Information SQL Server is  Multi-instance Aware  1 Default Instance, multiple named instances  Has the ability to listen on TCP, named pipes, VIA, HTTP (new in SQL 2005)  More protocols were in SQL Server 2000  TCP 1433 and UDP 1434 reserved

SQL Server Security Model Client Connection Scenario Establish login credentials Connect to the SQL Server computer Verify permissions for all actions within a database 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 a database context

SQL Server Security Modes  Windows ® Authentication security mode  Only accept logins using Windows NT ® / Windows 2000 credentials  Implements network-wide single sign-on  Mixed security mode  Allows Windows logins  Allows SQL Server-based logins  Basic Authentication scheme

Logins  A Login gives you connection rights  Is contained in the master database  Server-wide scope  Server-level permissions grantable  Membership in server roles  New DDL: CREATE / ALTER / DROP LOGIN

Login DDL CREATE LOGIN login_name { WITH | FROM } ::= WINDOWS [ WITH [,...] ] | CERTIFICATE certname | ASYMMETRIC KEY asym_key_name ::= WINDOWS [ WITH [,...] ] | CERTIFICATE certname | ASYMMETRIC KEY asym_key_name ::= ::= PASSWORD = 'password' [ HASHED ] [ MUST_CHANGE ] [, [,... ] ] ::= SID = sid | DEFAULT_DATABASE = database | DEFAULT_LANGUAGE = language | CHECK_EXPIRATION = { ON | OFF} | CHECK_POLICY = { ON | OFF} [ CREDENTIAL = credential_name ] ::= SID = sid | DEFAULT_DATABASE = database | DEFAULT_LANGUAGE = language | CHECK_EXPIRATION = { ON | OFF} | CHECK_POLICY = { ON | OFF} [ CREDENTIAL = credential_name ] ::= DEFAULT_DATABASE = database | DEFAULT_LANGUAGE = language ::= DEFAULT_DATABASE = database | DEFAULT_LANGUAGE = language

Users  A database User allows entry into database  Contained in every DB  Provides mapping to Logins  Specific to a single database  Membership in fixed or user defined DB roles  New DDL: CREATE / ALTER / DROP USER

User DDL CREATE USER user_name [ { { FOR | FROM } { LOGIN login_name | CERTIFICATE cert_name | ASYMMETRIC KEY asym_key_name } | WITHOUT LOGIN ] [ WITH DEFAULT_SCHEMA = schema_name ]

SQL Server Roles  Fixed server roles  Flexible server administration  Eg: Sysadmin, Serveradmin  Fixed database roles  Flexible database administration  Eg: db_ddladmin, db_owner  Flexible database roles  Custom security combinations  Application roles  Assign rights to applications instead of users

Application Roles  Database-specific roles that do not contain members  Require a password to be activated  sp_setapprole  Once activated, users cannot access other databases  Unless the guest account or public role has been created in the other database  New in SQL Server 2005: Ability to revert application roles  sp_unsetapprole

What Are Principals? Principals Permissions Securables Server Role SQL Server Login SQL Server Windows Group Domain User Account Local User Account Windows User Database Role Application Role Group Database

Principals Permissions Securables Server Role SQL Server Login SQL Server Windows Group Domain User Account Local User Account Windows User Database Role Application Role Group Database What Are Securables? Files Registry Keys Instance Schema Database

Principals Permissions Securables Server Role SQL Server Login SQL Server Windows Group Domain User Account Local User Account Windows User Database Role Application Role Group Database Files Registry Keys Instance Schema Database What Are Permissions? CREATE ALTER DROP CONTROL CONNECT SELECT EXECUTE UPDATE DELETE INSERT TAKE OWNERSHIP VIEW DEFINITION BACKUP GRANT DENY REVOKE ACL

Agenda  SQL Server Security Overview  Authentication  Endpoints  Password Policy  SSL protection  Authorization  Auditing  Encryption  Surface Area Reduction  Best practices

Endpoint-Based Authentication  Endpoint:  Point of entry into an instance  Binds transport protocol to payload  HTTP, Service Broker, Database Mirroring  Endpoints need to be explicitly created  No permissions on endpoint by default  TCP, Named Pipes, Shared Memory  Default endpoint created at start up  CONNECT permissions granted to authenticated logins  Permissions can be denied on a per endpoint basis Transport Protocol Named Pipes Shared Memory TCP HTTP VIA Payloads TDS SOAP SSB Database Mirroring

SQL Server Security Model Using Endpoints Establish login credentials Establish login credentials Authorize against Endpoint Connect to the SQL Server computer Verify permissions for all actions 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 a database context

Password Policy Enforcement  Enforcement of the following on logins  Password Strength  Password Expiration  Account Lockouts  Follows local Windows password policy  Supports consistent enterprise-wide policy  Approach  New password policy check API  Only available on Windows Server 2003 and above  On previous versions, rudimentary complexity check

Login-Level Options  Server-Side Options  Check_Policy – Default ON  Check_Expiration – Default OFF  Must_Change – SQL Server logins only  DISABLE  Client-Side Support  Password change at login

Protecting SQL Credentials  Requires a secure channel  IPSEC, SSL  In previous releases required admin to setup SSL / IPSEC certificate  Not secure by default  In SQL Server 2005  SSL certificate automatically generated  Prevents passive man-in-the-middle attacks

Protecting the Channel Transfer un-encrypted data DB1 DB2 SQL Server2 Usernamepassword Usernamepassword Usernamepassword

Protecting the Channel DB1 DB2 SQL Server Usernamepassword Transfer data over an encrypted channel

Encryption Over the Wire  Login Credentials Encryption  Uses SSL certificate from certificate store (if available)  Can be explicitly chosen using Certificate Picker  Otherwise, will use SQL-generated certificate  Data packets can be encrypted  Server-Side Option: ‘Force Protocol Encryption’  Client-Side: Encryption with or without certificate validation

Agenda  SQL Server Security Overview  Authentication  Authorization  Permissions and Scopes  Schemas  Ownership Chaining and Execution Context  Auditing  Encryption  Surface Area Reduction  Best practices

Granular Permissions  Principle of Least Privileges  Multiple permissions – various scopes  Choice of permission granularity and scope  Scopes  Server: Example: ALTER ANY LINKED SERVER  Database: Example CREATE TABLE  Schema: Example ALTER  Object: Example SELECT  Permission Granularity:  Example: ALTER permission on an object  Example: ALTER TRACE permission

Schemas New in SQL Server 2005  Fully qualified names  SQL Server 2000: Server.Database.Owner.Object  SQL Server 2005: Server.Database.Schema.Object  Users (owners) and schemas have been separated  Were the same in previous releases  Objects contained in schemas  Separation allows for better security management  Offers better namespace management from application perspective

General Permissions Scheme  Grantee  Logins for server-level permissions  Database principals for database-level permissions  Securable  Entity to be secured  Tables, assemblies, databases, server, etc…  Same permission can be at multiple scopes  Example: CONTROL at schema or table level  DENY at any level always takes precedence

Scope and Granularity Database Schema 1 Table1View1 View 2 Schema 2 Schema 3 Stored Proc Function

Covering Permissions  Permissions can be derived from grants at higher scope  Example: EXECUTE granted at schema level  Permissions can be implied by other permissions  Example: CONTROL on a table implies SELECT  sys.fn_mypermissions()  Ability to find out what permissions a user has

Permissions Metadata  sys.server_permissions  Server-level permissions  sys.database_permissions  Database-level permissions  sys.securable_classes  Lists all securables  sys.fn_builtin_permissions  Shows all permissions grantable on a securable  Includes covering permissions

Ownership Chaining and Execution Context User 3 Select Permissions checked for User3 Execute Permissions checked for User3 User1.Proc1 User1.T1 NO Permissions checked for User3 User 3 User2.Proc1 User1.T1 ‘Execute AS ‘X’ ’ Execute Permissions checked for User3 Select Permissions checked for ‘X’. Not for user3 SQL Server 2005 SQL Server 2000 User2.Proc1User1.T1

Module Execution Context  Ability to choose execution context of modules  Stored procedures, functions, triggers  Include WITH EXECUTE AS in module definition  No need to rely on ownership chaining to get ‘upfront permission check’ behavior  Ownership chaining rules still apply however  Permissions checked against current execution context  Option available for dynamic SQL as well  EXECUTE ('…') AS USER = 'User1';  Execution context maintained in the sys.sql_modules catalog view

Module Execution Context CREATE PROCEDURE dbo.usp_Demo WITH EXECUTE AS 'Domain\SqlUsr1' AS SELECT user_name();  Execute AS CALLER  Statements execute as immediate calling context  Default behavior, similar to SQL Server 2000  Execute AS ‘UserName’  Statements execute as the username specified  Impersonate permission required on user specified  Execute AS SELF  Statements execute as the creator/modifier of the module  Execute AS OWNER  Statements execute as the current owner of the module

Using Execute As to create permission buckets  Scenario:  Database Admin wants to delegate the ability to truncate a set of tables each night  Problem:  Truncate is not a grantable permission  Closest covering permission is ALTER, but that is too high and gives other ability  Solution: Execute As to the rescue  Create a Proc that truncates the table  Mark it to execute as a user with ALTER permissions  Grant execute permission to the target user  Result:  You’ve just made Truncate a grantable permission!!!

Creating Custom Permission Sets Execute AS 'X' Execute permissions checked for User3 Select permissions checked for 'X‘, not for User3 User3User2.Proc1User1.Table1 Original Login always audited

Cross-Database Ownership Chaining User1.SP1 User1.Tab1 Login1 End_User Cross DB Ownership Chaining = 1 DB_Chaining = 1 Execute Permissions checked for End_User No Permissions checked

Agenda  SQL Server Security Overview  Authentication  Authorization  Auditing  Encryption  Surface Area Reduction  Best practices

But what about metadata?  System tables implemented as views: catalog views  Metadata is secured by default  Minimal permissions to public  Catalog views are row-level secured  Need to be owner or have some permission on object to see it in catalog view  SA can see everything in server  DBO can see everything in database  New permission to allow viewing of metadata  VIEW DEFINITON  Applicable at object level, schema level, database and server level

Data Access Audit  SQL Trace – the server side of profiling  Auditing is performed by SQL Trace – internal to SQL Server  Exposed through stored procedures  Can be called directly or through the SQL Server Profiler UI  SQL Server 2005 introduces new audit events around impersonation and schema management

Login Auditing  Record of login activity  Necessary to keep track of potential brute force attempts  SQL Server 2005 defaults to auditing failed login attempts  Audit events written to error log and Windows application log

Custom Auditing  DML triggers  Can be used to audit data modifications in a custom manner  DDL triggers  New in SQL Server 2005  Custom audit DDL changes  Event notifications  Uses Service Broker  Asynchronous audit of operations USE AdventureWorks GO CREATE EVENT NOTIFICATION NotifyALTER_T1 ON DATABASE FOR ALTER_TABLE TO SERVICE '//AdventureWorks.com/ArchiveService', '8140a771-3c4b ac ab17984';

Agenda  SQL Server Security Overview  Authentication  Authorization  Auditing  Encryption  Surface Area Reduction  Best practices

Data Encryption  Why consider encryption?  Additional layer of security  Required by some regulatory compliance laws  In SQL Server 2000, vendor support required  In SQL Server 2005  Built-in support for data encryption  Support for key management

Cryptography Symmetric Key Encryption 0x E4FA2… Encryption Decryption x E4FA2… Encryption with public key Decryption with private key Public Key Private Key Asymmetric Key Encryption

Encryption and Decryption Built-in Functions  EncryptByKey ( )EncryptByAsymKey ( )  EncryptByCert ( )EncryptByPassPhrase ( )  Each with corresponding DecryptByXxx ( )  ALTER TABLE HumanResources.Employee ADD EncryptedNatIDNumber varbinary(128) -- Open the symmetric key to encrypt data OPEN SYMMETRIC KEY SSN_Key_01 DECRYPTION BY CERTIFICATE HR037; -- Encrypt the value in column NationalIDNumber -- with symmetric key SSN_Key_01, saving the -- result in column EncryptedNatIDNumber UPDATE HumanResources.Employee SET EncryptedNatIDNumber = EncryptByKey( Key_GUID('SSN_Key_01'), NationalIDNumber );

SQL Server 2005 support  Encryption and Decryption built-ins  DDL for creation of  Symmetric Keys  Asymmetric Keys and Certificates  Symmetric Keys and Private Keys are always stored encrypted  Securing the Keys themselves  Based on user passwords  Automatic, using SQL Server key management

It’s all about the Keys  Encryption keys need to be protected  Some keys need to be backed up  If the keys are lost, data may be lost  Therefore, ability to restore keys must exist  Keys may need to be regenerated  In case of compromise of the keys  Keys may need to be shared across systems  In the case, where encrypted data is being shared

Encryption Support Key Another key User Password Certificate Database entity created byDatabase entity created by CREATE KEY DDL Always stored encryptedAlways stored encrypted Secured in one of three waysSecured in one of three ways Public Key Private Key Password Master Key DPAPI Database entity created byDatabase entity created by CREATE CERTIFICATE DDL Always private keysAlways private keys stored encrypted Secured in one of two waysSecured in one of two ways Secured By Secured By Wraps the … Wraps the … Secured By Secured By Associated with… Associated with… Service Key Secured By Secured By

Database Master Key  Secures private keys inside the database  Explicitly created by owner of the database  Support for regeneration and recovery  ALTER MASTER KEY DDL  BACKUP / RESTORE MASTER KEY DDL  Always secured using user password  Stored in the database  Can also be secured using Service Master Key  Always take a backup!

Service Master Key  Used to secure system data  Linked server passwords  Database Master keys  Proxy credentials  Created upon first use  Support for regeneration and recovery  ALTER SERVICE MASTER KEY DDL  BACKUP / RESTORE SERVICE MASTER KEY DDL  Secured using DPAPI  The service accounts credentials  Always take a backup!

Agenda  SQL Server Security Overview  Authentication  Authorization  Auditing  Encryption  Surface Area Reduction  Best practices

Surface Area Configuration  Secure By Default on new installs  Minimal default surface area  Default install image that is safe and usable  Heterogeneity in our install base  Poses hurdles for large-scale exploits  More administrator control  Choice to run features only as needed  To lockdown features centrally and easily  Reduction in administrative complexity

Approach  Install-time options  Admin choice of services to install at setup time  Disabled/Stopped Services:  Helper services installed as part of another service  Typically help with specific features  Eg: MSADHelper, Browser, SQL Writer, Agent, etc.  These are disabled and stopped by default  Feature-level knobs  On/Off switches for specific features (old and new)  Features requiring explicit configuration  Network Communication  Knobs to turn on or off specific communication protocols

Ad hoc DQ xp_cmdshell OLE Automation SPs SMO/DMO XPs SQLiMail XPs SQLMail XPs CLR Webtasks XPs Web Service Requests Scheduled Events and Report Delivery Helper Services Components Communication Protocols Services SQL Server Box MSADHelper Service SQL Server Agent SQL Writer Service SQL Browser Service Communication Protocols and Endpoints Fulltext / MSSearch Allow Anonymous Connections Ad hoc OpenRowset Queries COM User-Defined Functions Local Only Connections Remote Partitions and Linked Objects SQL Server Service Integration Services Reporting Services Analysis Services Notification Services Surface Area Configuration

Surface Area Configuration Tool  Tool to centrally control the SQL Server surface area  Launch-able from setup  Available in Start menu  Provides some guidance when turning features on or off  Scripting capability

Agenda  SQL Server Security Overview  Authentication  Authorization  Auditing  Encryption  Surface Area Reduction  Best Practices  Security Diagnostics  Secure Installation  Secure Operations

Security Diagnostics…  Run MBSA periodically  Scan for and remove accounts with NULL passwords and where check_policy is off  Remove unused logins  Scan for objects with permissions granted to public  Verify login-user mapping  Interesting in attach/detach scenarios  sp_change_users_login with report option  Enumerate membership in privileged roles  Ensure membership to trusted individuals only  Ensure start-up procedures are safe and trusted  Periodically scan the surface area that is enabled

Secure Installation  Physical security  Protect all related systems, media, backups, etc.  Never place RDBMS unprotected on the network  Firewall protected  Software mediating database access  Install on NTFS file system  This allows securing the files appropriately  Isolate Services  Do not install on a Domain Controller  Use low privilege service account  Do not use LocalSystem, Local or Domain Administrator  Prevents compromised database to be used to bootstrap access to rest of enterprise  Latest code is most secure code  Apply latest service packs and security patches!

Secure Operations (1 of 2)  Run the prescribed security diagnostics periodically  Only configure and run needed features  xp_cmdshell usage  Do not change default permissions  Never set proxy account to administrator  In SQL Server 2005 proxy account does not require service account to be admin  Smallest possible admin groups  Changing service accounts  Use SQL Server Tools  Disallow direct catalog updates

Secure Operations (2 of 2)  Media security including backups  Have aggressive backup policy  Test disaster recovery system  Turn on appropriate level of auditing  Track critical user actions at a minimum  Keep overhead at a minimum  Encryption options  Protect sensitive data over the wire  Use SSL, IPSEC etc.  File-level encryption  Prevents illicit copying of database files  SQL Server supports Encrypted File System (EFS)

Summary  SQL Server Security Overview  Background  Principals, Securables, Permissions  Authentication  Endpoints  Password Policy  SSL protection  Authorization  Permissions and Scopes  Schemas  Ownership Chaining and Execution Context  Auditing  Encryption  Surface Area Reduction  Best Practices

For More Information  SQL Server Books Online  Whitepapers  Security in SQL Server 2005  MSDN and TechNet webcasts

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