Where should I be encrypting my data?
•
0 likes•1,081 views
Presentation by Shree Prasad Khanal, Leader, Himalayan SQL Server User Group, on "Where should I be encrypting my data? " at "Braindigit 9th National ICT Conference 2013" organized by Information Technology Society, Nepal at Alpha House, Kathmandu, Nepal on 26th January, 2013
Recommended
More Related Content
What's hot
What's hot (19)
Viewers also liked
Viewers also liked (16)
Similar to Where should I be encrypting my data?
Similar to Where should I be encrypting my data? (20)
Recently uploaded
Recently uploaded (20)
Where should I be encrypting my data?
- 1. Where should I be encrypting my data?
- 2. About Me • Independent Consultant • Founder of SQL Helps (www.sqlhelps.com) • Leader & Founder (Himalayan SQL Server User Group) • Microsoft Certified Trainer 2
- 3. Overview • Overview of SQL Server Security • Protecting the Server Scope • Protecting the Database Scope • Managing Keys and Certificates • Auditing Security
- 4. Lesson 1: Overview of SQL Server Security • SQL Server Security Framework • What Are Principals? • What Are Securables? • SQL Server Permissions
- 5. SQL Server Security Framework
- 6. What Are Principals? Securables Permissions Principals Windows Group Domain User Account Windows Local User Account SQL Server Login Server Role SQL Server User Database Role Database Application Role
- 7. What Are Securables? Securables Permissions Principals Windows Group Files Domain User Account Registry Keys Windows Local User Account SQL Server Login Server Server Role SQL Server Database User Schema Database Role Database Application Role
- 8. SQL Server Permissions Server-Level Permissions Logins Credentials Server-Level Roles Database-Level Permissions Users Schemas Database-Level Roles
- 9. Lesson 2: Protecting the Server Scope • What Are SQL Server Authentication Methods? • Password Policies • Server-Level Roles • Managing SQL Server Logins • Delegation Between Instances • What Are Credentials? • Server-Scope Permissions
- 10. What Are SQL Server Authentication Methods? Windows Authentication Mixed SQL and Windows Authentication
- 11. Password Policies SQL Server Can Leverage Windows Server 2003/2008 Password Policy Mechanism Pa$$w0rd Group Policy Object (GPO) SQL Server Can Manage: • Password Complexity • Password Expiration • Policy Enforcement
- 12. Server-Level Roles Role Description sysadmin Perform any activity dbcreator Create and alter databases diskadmin Manage disk files serveradmin Configure server-wide settings securityadmin Manage and audit server logins processadmin Manage SQL Server processes bulkadmin Run the BULK INSERT statement setupadmin Configure replication and linked servers
- 13. Managing SQL Server Logins CREATE LOGIN [SERVERXSalesDBUsers] login_name CREATE LOGIN Alice FROM WITH SQL_login_options { WINDOWS = 'Pa$$w0rd' WITH Password WITH |DEFAULT_DATABASE WITH FROM WINDOWS [ = AdventureWorks2008 windows_login_options ] }
- 14. Delegation Between Instances Client Server TCP/IP or Named Pipes Registered De le Trusted for delegation g at io n! Linked Server Self Mapping TCP/IP or Named Pipes
- 15. What Are Credentials? SQL Credentials Contain windows authentication information Allow SQL Accounts to connect to non-SQL resources SQL Logins can only map to one credential Created automatically. Associated with specific endpoints
- 16. Server-Scope Permissions Server permissions USE master GRANT ALTER ANY DATABASE TO [AdventureWorks2008Holly] Server-scope securable permissions USE master GRANT ALTER ON LOGIN :: AWWebApp TO [AdventureWorks2008Holly]
- 17. Demonstration: Managing Logins In this demonstration we will: • Connect to SQL Server • Create a Windows Login • Create a SQL Server Login
- 18. Lesson 3: Protecting the Database Scope • What Are Database Roles? • What Are Application Roles? • Managing Users • Special Users • Database-Scope Permissions • Schema-Scope Permissions • Ownership Chains • Applying Roles in Common Scenarios
- 19. What Are Database Roles? Database-Level Roles Application-Level Roles Users
- 20. What Are Application Roles? User runs app App connects App authenticates to db as user using sp_setapprole App assumes app role
- 21. Managing Users Steps to Manage Users 1 Create a login 2 Create a database scope user 3 Assign permissions to the user
- 22. Special Users DBO The sa login and members of sysadmin role are mapped to dbo account Guest This user account allows logins without user accounts to access a database
- 23. Database-Scope Permissions Database permissions USE AdventureWorks2008 GRANT ALTER ANY USER TO HRManager Database-scope securable permissions USE AdventureWorks2008 GRANT SELECT ON SCHEMA :: Sales TO SalesUser
- 24. Schema-Scope Permissions User-defined type permissions USE AdventureWorks2008 GRANT EXECUTE ON TYPE :: Person.addressType TO SalesUser All other schema-scope permissions USE AdventureWorks2008 GRANT SELECT ON Sales.Order TO SalesUser
- 25. Ownership Chains 1 6 2 3 4 5
- 26. Applying Roles in Common Scenarios Database-Level Roles Common Scenarios dbo – database owner Read-only users Data authors – Read / Write / Delete
- 27. Demonstration: Managing Roles and Users In this demonstration we will: • Create new users for Windows groups and users, and the App SQL Server Login • Assign roles to users and verify users’ permissions • Create a new customer database role and add a user to the role
- 28. Lesson 4: Managing Keys and Certificates • What Are Keys? • What Are Certificates? • SQL Server Cryptography Architecture • When to Use Keys and Certificates • Transparent Data Encryption
- 29. What Are Keys? Encrypt Decrypt • Symmetric Same key used to encrypt and decrypt • Asymmetric Pair of values: public key and private key One encrypts, the other decrypts
- 30. What Are Certificates? • Associates a public key with entity that holds that key • Contents: The public key of the subject The identifier information of the subject The validity period Issuer identifier information The digital signature of the issuer
- 31. SQL Server Cryptography Architecture
- 32. When to Use Keys and Certificates When to use Certificates To secure connections in database mirroring To sign packets To encrypt data or connections When to use Keys To help secure data To sign plaintext To secure symmetric keys
- 33. Transparent Data Encryption Transparent data encryption performs real-time I/O encryption and decryption of the data and log files Steps to use Transparent Data Encryption Create a master key Create or obtain a certificate protected by the master key Create a database encryption key and protect it by the Certificate Set the database to use encryption
- 34. Demonstration: Encrypting and Decrypting Data In this demonstration we will: • Create a table • Create keys and a certificate • Encrypt and decrypt data using the certificate • Attempt to access encrypted data as an unauthorized user
- 35. Lesson 5: Auditing Security • Discussion: What Is Auditing? • Security Auditing with Profiler • Auditing with DDL Triggers • Introducing SQL Server Audit • SQL Server Audit Action Groups and Actions
- 36. Discussion: What Is Auditing? • What is Auditing? • What auditing options are available in SQL Server? • Have you ever had to audit SQL Server? • If so, how did you do it? • If not, what do you think is the best use of auditing?
- 37. Security Auditing with Profiler Using SQL Server Profiler, you can do the following: Create a trace that is based on a reusable template Watch the trace results as the trace runs Store the trace results in a table Start, stop, pause and modify the trace results Replay the trace results
- 38. Auditing with DDL Triggers Use DDL triggers when you want to do the following Prevent certain changes in your database schema You want something to occur in the database in response to a change in your database schema You want to record changes or events in the database schema Start, stop, pause and modify the trace results Replay the trace results
- 39. Introducing SQL Server Audit SQL Server Auditing Tracks and logs events that occur on the system Can track changes on the server or database level Can be managed with Transact-SQL
- 40. SQL Server Audit Action Groups and Actions SQL Server Audit Action Groups consist of: Server-Level Audit Action Groups Database-Level Audit Action Groups Audit-Level Audit Action Groups
- 41. Demonstration: Using SQL Server Audit In this demonstration we will: • Create a SQL Server Audit and define its target • Create and enable an audit specification • Create an auditable event and view the event in the Windows Event Viewer
- 42. Lab: Managing Security • Exercise 1: Creating Logins and Assigning Server-Scope Permissions • Exercise 2: Creating Database Users and Assigning Database-Scope and Schema-Scope Permissions • Exercise 3: Encrypting Data Using Certificates and Keys • Exercise 4: Implementing SQL Server Audit Logon information Virtual machine NY-SQL-01 User name Student Password Pa$$w0rd Estimated time: 120 minutes
- 43. Lab Scenario The Senior Database Administrator for Adventure Works has asked you to implement a security solution that meets the following security requirements for the SQL Server NY-SQL-01: • Configure permissions for various groups and users to meet specific access needs. • The Human Resources department would like to be able to store details of employee review meetings. The notes concerning each meeting are highly confidential and must be stored in such a fashion that only the HRApp user can read them. • You must also enable and verify auditing.
- 44. Lab Review • What is the importance of password policies? • How can server and database scope permissions be used to manage organizational access to data? • What are some of the benefits of encryption? • How can SQL Server audits be used to make management tasks easier?
- 45. Module Review and Takeaways • Review Questions • Real-world Issues and Scenarios • Best Practices
Editor's Notes
- Module 4: Managing Security Course 6231A
- Module 4: Managing Security Course 6231A
- Module 4: Managing Security Course 6231A
- Module 4: Managing Security Course 6231A On this slide, you will learn the SQL Server Security Framework. Don’t focus too much on the details of all the items shown here because most of them are covered in more detail later on. This illustration shows the relationships among the Database Engine permissions hierarchies. The Database Engine manages a hierarchical collection of entities that can be secured with permissions. These entities are known as securables . The most prominent securables are servers and databases, but discrete permissions can be set at a much finer level. SQL Server regulates the actions of principals on securables by verifying that they have been granted appropriate permissions. Working with Permissions: Permissions can be manipulated with the familiar Transact-SQL queries GRANT, DENY, and REVOKE. Information about permissions is visible in the sys.server_permissions and sys.database_permissions catalog views. Inherited Permissions: Certain permissions in Microsoft ® SQL Server® 2008 can be inherited through a permission granted at a higher level in the securable scope hierarchy. A principal granted CONTROL permission on a database object will automatically inherit CONTROL permission on all securables contained in that database and all securables contained in the schemas within that database. Effective Permissions: The effective permissions for a principal are evaluated in the same way as in previous releases of SQL Server. A principal can perform a particular action if both of the following are true: Kerberos Authentication and SQL Server: Kerberos is a network authentication protocol provides a highly secure method to authenticate client and server entities (security principals) on a network. These security principals use authentication that is based on master keys and encrypted tickets. Kerberos with SQL Server SQL Server supports Kerberos indirectly through the Windows Security Support Provider Interface (SSPI) when SQL Server is using Windows authentication. SSPI allows an application to use various security models available on a computer or network without changing the interface to the security system. What users and groups need SQL Server access in your organization? References: For more information about Kerberos authentication with SQL Server, see “Kerberos Authentication and SQL Server”, http://go.microsoft.com/fwlink/?LinkID=127652 For more information about the permissions hierarchy, see “Permissions Hierarchy”, http://go.microsoft.com/fwlink/?LinkID=127657
- Module 4: Managing Security Course 6231A Begin with an overview of SQL Server Security Principals. You should be able to build from the previous slide as you give more detail on the items in the framework. Point out how these levels are different from each other. Principals are entities that can request SQL Server resources. Like other components of the SQL Server authorization model, principals can be arranged in a hierarchy. A Windows® Login is an example of an indivisible principal, and a Windows Group is an example of a principal that is a collection. Every principal has a security identifier (SID). Windows-level principals Windows Domain Login Windows Local Login SQL Server-level principal SQL Server Login Database-level principals Database User Database Role Application Role References: For more information about principals, see “Principals”, http://go.microsoft.com/fwlink/?LinkID=127658
- Module 4: Managing Security Course 6231A On this slide, you will do an overview of database securables. Mention that as with principals, you need to understand the different securable scopes in SQL Server to plan your security model. Note that the securables contained in each scope are listed on the slide and not in the slide notes. Securables are the resources to which the SQL Server Database Engine authorization system regulates access. Some securables can be contained within others, creating nested hierarchies called "scopes" that can themselves be secured. The securable scopes are server , database , and schema . What are the key securables in your organization's SQL Server? Some examples could be Logins, Tables, Databases, Schemas, etc. References: For more information about securables, see “Securables”, http://go.microsoft.com/fwlink/?LinkID=127660
- Module 4: Managing Security Course 6231A On this slide, you will learn the SQL Server permissions hierarchy, specifically Server and Database level. Explain that SQL Server uses permissions to control access to securables by principals. To plan your database security model, it is important to understand how permissions are implemented in the securable scopes. SQL Server enables administrators to secure SQL server at different levels of atomicity. Sever-Level Permissions Logins Logins grant access to SQL Server resources. Logins can use one of two forms of access: Windows Authentication or SQL Server Authentication. Logins that utilize Windows Authentication use Windows user and group accounts to grant access to SQL Server. Logins that utilize SQL Server Authentication use username and password information stored natively in SQL Server. Credentials A credential is a record that contains the authentication information (credentials) required to connect to a resource outside SQL Server. This information is used internally by SQL Server. Most credentials contain a Windows user name and password. Server-Level Roles Server-Level Roles enable administrators to easily manage the permissions on your server, SQL Server provides several roles, which are security principals that group other principals. Roles are like groups in the Microsoft Windows operating system. Database-Level Permissions Users Users represent permissions at the database scope. Users map to logins and can be used to refine a given login’s permissions on a specific database Schemas Schemas represent a collection of securables within database. Securables in the schema scope include objects such as tables, views, stored procedures, and types Database-Level Roles To easily manage the permissions in your databases, SQL Server provides several roles which are security principals that group other principals. They are like groups in the Microsoft Windows® operating system. Database-level roles are database-wide in their permissions scope. References: For more information about permissions, see “Permissions”, http://go.microsoft.com/fwlink/?LinkID=127656 For more information about the different server-level roles, see “Server-Level Roles”, http://go.microsoft.com/fwlink/?LinkID=127663 For more information about the different database-level roles, see “Database-Level Roles”, http://go.microsoft.com/fwlink/?LinkID=127643
- Module 4: Managing Security Course 6231A
- Module 4: Managing Security Course 6231A On this slide, you will review SQL Server Authentication Modes. Explain how the two are different and the advantages\\disadvantages of both. Mention how Windows Authentication uses the Kerberos protocol. SQL Server has two authentication modes: Windows Authentication Mode SQL Server and Windows Authentication (or Mixed) Mode Windows Authentication Windows Authentication mode is the default (recommended) mode on installation of SQL Server. Windows Authentication leverages Active Directory user and group accounts to grant access to SQL Server. In this mode server administrators are able to grant server, database and object level permissions without managing a separate set of SQL Server Accounts. When using Windows Authentication Mode user accounts are subject to enterprise wide policies enforced by the Active Directory Domain such as complex passwords, password history, account lockouts, minimum password length, maximum password length and the Kerberos protocol. Use Windows Authentication Mode in network environments in which all users are authenticated through Windows user accounts. SQL Server and Window Authentication (a.k.a. Mixed Authentication) Mixed Authentication Mode can use either Active Directory user account or SQL Server accounts to grant access to SQL Server. SQL Server can optionally enforce policies such as password complexity password expiration and account lockouts. SQL Server accounts are managed independently of Windows and Active Directory. Use SQL Server and Windows Authentication mode when you must allow users or applications that do not have Windows credentials to connect to SQL Server. References: For more information about Kerberos authentication with SQL Server, see “Kerberos Authentication and SQL Server”, http://go.microsoft.com/fwlink/?LinkID=127652 For more information about the authentication modes, see “Choosing an Authentication Mode”, http://go.microsoft.com/fwlink/?LinkID=127635
- Module 4: Managing Security Course 6231A On this slide, you will review SQL 2008 Password Policy Features. Mention that SQL Server can leverage the Windows Server 2003/2008 Password Policy mechanism. Then review Password Complexity, Password Expiration, and Policy Enforcement. When it is running on Microsoft® Windows Server® 2003 or later, SQL Server can use Windows password policy mechanisms. SQL Server can apply the same complexity and expiration policies used in Windows Server 2003, or later, to passwords used inside SQL Server. This functionality depends on the NetValidatePasswordPolicy API, which is only available in Windows Server 2003 and later versions. Password Complexity Password complexity policies are designed to deter brute force attacks by increasing the number of possible passwords. When password complexity policy is enforced, new passwords must a number of guidelines. Password Expiration Password expiration policies are used to manage the lifespan of a password. When SQL Server enforces password expiration policy, users are reminded to change old passwords, and accounts that have expired passwords are disabled. Policy Enforcement The enforcement of password policy can be configured separately for each SQL Server login. Use ALTER LOGIN (Transact-SQL) to configure the password policy options of a SQL Server login. Does your organization employ a password policy? References: For more information about password policies, see “Password Policy”, http://go.microsoft.com/fwlink/?LinkID=127655
- Module 4: Managing Security Course 6231A On this slide, you will review Server-Level (aka Fixed Server) Roles. Explain each of the points covered in the slide and then give some examples of Server-Level roles. Roles are like groups in the Microsoft Windows operating system. Server-level roles are also named fixed server roles because you cannot create new server-level roles. Server-level roles are server-wide in their permissions scope. You can add SQL Server logins, Windows accounts, and Windows groups into server-level roles. Each member of a fixed server role can add other logins to that same role. Examples of some Server-Level Roles: sysadmin - Members of the sysadmin fixed server role can perform any activity in the server. By default, all members of the Windows BUILTIN\\Administrators group, the local administrator's group, are members of the sysadmin fixed server role. serveradmin - Members of the serveradmin fixed server role can change server-wide configuration options and shut down the server. dbcreator - Members of the dbcreator fixed server role can create, alter, drop, and restore any database. References: For more information about the different server-level roles, see “Server-Level Roles”, http://go.microsoft.com/fwlink/?LinkID=127663
- Module 4: Managing Security Course 6231A On this slide, you will review methods for managing SQL Server accounts. Mention that SQL Server logins can be managed with SQL Server Management Studio and with Transact-SQL statements. Discuss what can be managed with SQL Server Management Studio and then review the T-SQL statements that can be used. Show examples of the T-SQL statements (examples in Companion CD content). SQL Server accounts can be viewed, created, dropped and otherwise modified using the SQL Server Management Studio. Using Management Studio Accounts can be managed at the server level by expanding the Security\\Logins node in Management Studio. Accounts can be managed at the database level by expanding the Databases node, expanding the selected database and viewing it’s Security\\Users node. Using Transact SQL Accounts can be created, altered and dropped using Transact SQL statements. References: For more information about SQL Server logins, see “Security Node”, http://go.microsoft.com/fwlink/?LinkID=127662 For more information about the creating a SQL Server login, see “How to: Create a SQL Server Login”, http://go.microsoft.com/fwlink/?LinkID=127650
- Module 4: Managing Security Course 6231A On this slide, you will review the delegation between 2 instances of SQL Server. Use the simple example in notes to help explain this. You will also review the requirements for delegation for this scenario. SQL Server and Microsoft Windows can be configured to enable an instance of SQL Server to connect to another instance of SQL Server under the context of an authenticated Windows user. This arrangement is known as impersonation or delegation . Under delegation, the instance of SQL Server to which a Windows user has connected by using Windows Authentication impersonates that user when communicating with another instance. Security account delegation is required for distributed queries when a self-mapping is used for a specific login against a specific linked server. Delegation Requirements To illustrate the requirements for delegation, consider the following scenario: A user logs on to a client computer that connects to a server that is running an instance of SQL Server, SQLSERVER1 . The user wants to run a distributed query against a database on a linked server, SQLSERVER2 . This scenario, in which one computer connects to another computer to connect to a third computer, is called a double hop . Requirements for the Client The Windows authenticated login of the user must have access permissions to SQLSERVER1 and SQLSERVER2 . The user Active Directory property, Account is sensitive and cannot be delegated , must not be selected. The client computer must be using TCP/IP or named pipes network connectivity. Requirements for the First/Middle Server (SQLSERVER1) The server must have an SPN registered by the domain administrator. The account under which SQL Server is running must be trusted for delegation. The server must be using TCP/IP or named pipes network connectivity. The second server, SQLSERVER2 , must be added as a linked server. This can be done by running the sp_addlinkedserver stored procedure. For example: EXEC sp_addlinkedserver 'SQLSERVER2', N'SQL Server‘ The linked server logins must be configured for self mapping. This can be done by running the sp_addlinkedsrvlogin stored procedure. For example: EXEC sp_addlinkedsrvlogin 'SQLSERVER2', 'true‘ Requirements for the Second Server (SQLSERVER2) If using TCP/IP network connectivity, the server must have an SPN registered by the domain administrator. The server must be using TCP/IP or named pipes network connectivity. References: For more information about the Linked servers for delegation, see “Configuring Linked Servers for Delegation”, http://go.microsoft.com/fwlink/?LinkID=127637
- Module 4: Managing Security Course 6231A On this slide, you will define credentials. Explain each point covered on the slide. You can also review the syntax for creating credentials to give additional information to students. A credential is a record that contains the authentication information (credentials) required to connect to a resource outside SQL Server. This information is used internally by SQL Server. Most credentials contain a Windows user name and password. The information stored in a credential enables a user who has connected to SQL Server by way of SQL Server Authentication to access resources outside the server instance. When the external resource is Windows, the user is authenticated as the Windows user specified in the credential. A single credential can be mapped to multiple SQL Server logins. However, a SQL Server login can be mapped to only one credential. System credentials are created automatically and are associated with specific endpoints. Names for system credentials start with two hash signs (##). References: For more information about credentials, see “Credentials”, http://go.microsoft.com/fwlink/?LinkID=127640 For more information about creating credentials, see “Creating Credentials”, http://go.microsoft.com/fwlink/?LinkID=127639
- Module 4: Managing Security Course 6231A On this slide, you will cover granting permissions on server-scope securables. Explain that you can grant permissions using either SQL Server Management Studio or the GRANT T-SQL statement. Mention that the full syntax of the GRANT statement is complex. As a quick demo idea you can execute the code samples on the virtual machine. Granting Permissions on Server-scope Securables To grant permissions on securables in the server scope: Use Object Explorer in SQL Server Management Studio to view the properties of the login you want to grant permissions to. On the Securables tab, add the required securables and set the required permissions. You can also grant server-scope permissions by using the GRANT Transact-SQL statement with the following syntax. GRANT { securable_permission [ ,...n ] } [ON securable_type :: securable_name] TO login [ ,...n ] [ WITH GRANT OPTION ] [ AS { group | role } ] The full syntax of the GRANT statement is complex. The syntax diagram above has been simplified to draw attention to its structure. References: For more information about the GRANT Transact-SQL statement, see “GRANT (Transact-SQL)”, http://go.microsoft.com/fwlink/?LinkID=127648 For more information about permissions, see “Permissions”, http://go.microsoft.com/fwlink/?LinkID=127656 For more information about the different server-level roles, see “Server-Level Roles”, http://go.microsoft.com/fwlink/?LinkID=127663
- Module 4: Managing Security Course 6231A In this demonstration, you will connect to SQL Server and create both a Windows credential login and a SQL credential login. For this demonstration, perform the following tasks: Creating the Window Credential Login Start NY-SQL-01 and login as Student . Open Server Manager . In console tree, expand Configuration | Local Users and Groups | Users . Create a new User named Frank with a Password of Pa$$w0rd . Open SQL Server Management Studio . Connect to the default server instance using Windows Authentication . Open the E:\\Mod04\\Democode\\Demonstration Code Snippets.sql file. Under the -- Create Window Credential Login comment, execute the code. The Window Credential Login should now be created. Creating the SQL Credential Login In Demonstration Code Snippets.sql, under the -- Creating SQL Credential Login comment, execute the code. The SQL Credential Login should now be created. Do you prefer to use SQL Server Management Studio or Transact-SQL to create logins? Why?
- Module 4: Managing Security Course 6231A
- Module 4: Managing Security Course 6231A On this slide, you review database roles. First describe what Database-Level Roles are. Then review Database-Level Roles, Application-Level Roles, and Users. Application-Level Roles will be covered in more detail in the next topic so don’t go into too much detail here. To easily manage the permissions in your databases, SQL Server provides several roles which are security principals that group other principals. Database-level roles are database-wide in their permissions scope. Database-Level Roles There are two types of database-level roles in SQL Server: fixed database roles that are predefined in the database and flexible database roles that you can create. Fixed database roles are defined at the database level and exist in each database. Members of the db_owner and db_securityadmin database roles can manage fixed database role membership. However, only members of the db_owner database role can add members to the db_owner fixed database role. You can add any database account and other SQL Server roles into database-level roles. Each member of a fixed database role can add other logins to that same role. Members of the db_owner fixed database role can perform all configuration and maintenance activities on the database, and can also drop the database. Application-Level Roles An application role is a database principal that enables an application to run with its own, user-like permissions. You can use application roles to enable access to specific data to only those users who connect through a particular application. Unlike database roles, application roles contain no members and are inactive by default. Database Users A database user is a principal at the database level. Every database user is a member of the public role. References: For more information about the different database-level roles, see “Database-Level Roles”, http://go.microsoft.com/fwlink/?LinkID=127643
- Module 4: Managing Security Course 6231A On this slide, you will learn Application Roles. First describe Application Roles and give more detail than on the previous topic. Then describe the steps involved in connecting with an Application Role. An application role is a database principal that enables an application to run with its own, user-like permissions. You can use application roles to enable access to specific data to only those users who connect through a particular application. Unlike database roles, application roles contain no members and are inactive by default. Application roles work with both authentication modes. Application roles are enabled by using sp_setapprole , which requires a password. Because application roles are a database-level principal, they can access other databases only through permissions granted in those databases to guest . Therefore, any database in which guest has been disabled will be inaccessible to application roles in other databases. In SQL Server, application roles cannot access server-level metadata because they are not associated with a server-level principal. To disable this restriction and thereby allow application roles to access server-level metadata, set the global flag 4616. Connecting with an Application Role The following steps make up the process by which an application role switches security contexts: A user executes a client application. The client application connects to an instance of SQL Server as the user. The application then executes the sp_setapprole stored procedure with a password known only to the application. If the application role name and password are valid, the application role is enabled. At this point, the connection loses the permissions of the user and assumes the permissions of the application role. References: For more information about the different application roles, see “Application Roles”, http://go.microsoft.com/fwlink/?LinkID=127633
- Module 4: Managing Security Course 6231A On this slide, you will overview basic user management in SQL Server. Describe how logins and database users work together. Describe how to create logins, users, and how to assign permission to users. In most cases, database users are mapped to logins. For example, you might create a user named Holly in the AdventureWorks2008 database to make that database accessible by a login named AdventureWorks\\Holly. By default, all logins with membership of the sysadmin fixed server role are mapped to the dbo user in all databases. Creating Logins Logins are created at the server scope and are mapped wither to SQL accounts or windows credentials. To create a new login in Management Studio Expand the Security > Logins node under the server instance. Right-click the Logins node and select New Login . In the New Login dialog, you can specify a Windows credential as the login or create a new SQL account username. Creating Users Users represent permissions at the database scope. Users map to logins and can be used to refine a given login’s permissions on a specific database. To create a user: Expand the selected database’s security node. Right-click the Users node, select New User . Create a new username and specify the login you wish to map the user to (note usernames and login names may be different). Specify any permissions for the selected user. Assigning Permissions to Users You can use the Securables page to set permissions on database securables for a user, database role or application role. This page only shows permissions that are explicitly granted or denied to this user or role. The principal may inherit additional permissions through membership in a group or role. Permissions inherited from a group or role are not listed in the grid. The sum of all of the explicit and implicit permissions of the principal constitutes its effective permissions. Which method of user modification are you most likely to use? References: For more information about how to manage logins and users, see “Managing Logins and Users How-to Topics”, http://go.microsoft.com/fwlink/?LinkID=127653 For more information about database users, see “Database User”, http://go.microsoft.com/fwlink/?LinkID=127642 For more information about the user and role properties, see “User or Role Properties”, http://go.microsoft.com/fwlink/?LinkID=127670
- Module 4: Managing Security Course 6231A On this slide, you will do an overview of special user accounts in SQL Server. Mention that there are 2 special users, DBO and Guest. These accounts have not changed in recent versions so you might consider doing a discussion for this topic in case this is not new for students. dbo The dbo is a user that has implied permissions to perform all activities in the database. Any member of the sysadmin fixed server role who uses a database is mapped to the special user inside each database called dbo . Also, any object created by any member of the sysadmin fixed server role belongs to dbo automatically. The dbo user cannot be deleted and is always present in every database. guest The guest user account allows logins without user accounts to access a database. Login accounts assume the identity of the guest user when the following conditions are met: The login account has access to SQL Server but does not have access to the database through its own user account. The guest account has been enabled. The guest account can be added to a database to allow anyone with a valid SQL Server login to access the database. The guest username is a member of the public role. After the guest user has been added to a database, any individual with a valid SQL Server login[md]regardless of security mode[md]can access the database as the guest user. A guest user works as follows: SQL Server checks to see whether the login ID has a valid username or alias assigned. If so, SQL Server grants the user access to the database as the username or aliases. SQL Server checks to see whether a guest username exists. If so, the login ID is granted access to the database as guest. If the guest account does not exist, SQL Server denies access to the database. References: For more information about the Special Users, see “Glossary definitions for Special Users”, http://go.microsoft.com/fwlink/?LinkID=127647
- Module 4: Managing Security Course 6231A On this slide, you review database scope permissions. Mention that you can grant permissions using SQL Server Management Studio or the GRANT T-SQL statement. Mention that the full syntax of the GRANT statement is complex. Types of Database-scope Permissions Database-scope permissions are permissions that can be applied to securables in the database scope, such as users, schemas, roles, assemblies, and Service Broker objects. Granting Database Permissions You can grant permissions on a database by using Object Explorer in SQL Server Management Studio or by using the GRANT Transact-SQL statement with the following syntax. GRANT { database_permission [ ,...n ] } TO security_account [ ,...n ] [ WITH GRANT OPTION ] [ AS { group | role } ] What is your preference for assigning permissions: Transact-SQL, SQL Server Management Studio? Why? References: For more information about the GRANT Transact-SQL statement, see “GRANT (Transact-SQL)”, http://go.microsoft.com/fwlink/?LinkID=127648 For more information about permissions, see “Permissions”, http://go.microsoft.com/fwlink/?LinkID=127656 For more information about the different database-level roles, see “Database-Level Roles”, http://go.microsoft.com/fwlink/?LinkID=127643
- Module 4: Managing Security Course 6231A On this slide, you review schema scope permissions. Give a very brief definition of a schema and then describe the schema-scope permissions. As with Server and Database scope permissions, you also grant schema scope permissions using SQL Server Management Studio or the GRANT T-SQL statement. A schema is a container that holds tables, views, procedures, and so on. It is inside a database, which is inside a server. These entities fit together like nested boxes. Securables in the schema scope include objects such as tables, views, stored procedures, and types. Schema-scope Permissions The following lists some of the permissions applicable in the schema scope. Securable Type: Schema SELECT Select rows from any object in the schema ALTER Alter any object in the schema TAKE OWNERSHIP Take ownership of the schema Securable Type: Table SELECT Select rows from the table ALTER Alter the table CONTROL Full control of the table References: For more information about the GRANT Transact-SQL statement, see “GRANT (Transact-SQL)”, http://go.microsoft.com/fwlink/?LinkID=127648 For more information about permissions, see “Permissions”, http://go.microsoft.com/fwlink/?LinkID=127656 For more information about schemas, see “Schemas”, http://go.microsoft.com/fwlink/?LinkID=127659
- Module 4: Managing Security Course 6231A On this slide, you will describe Ownership Chains. First describe what they are and how they work. Then talk about how Permissions are checked in a chain. Finally walk through the example of an Ownership Chain. Understanding SQL Ownership Chains Although chains do not independently exist, when SQL Server traverses the links in a chain, SQL Server evaluates permissions on the constituent objects differently than it would if it were accessing the objects separately. These differences have important implications for managing security. How Permissions Are Checked in a Chain When an object is accessed through a chain, SQL Server first compares the owner of the object to the owner of the calling object. This is the previous link in the chain. If both objects have the same owner, permissions on the referenced object are not evaluated. Example of Ownership Chaining (Slide Graphic) In the following illustration, the July2003 view is owned by Mary. She has granted to Alex permissions on the view. He has no other permissions on database objects in this instance. What occurs when Alex selects the view? Alex executes SELECT * on the July2003 view. SQL Server checks permissions on the view and confirms that Alex has permission to select on it. The July2003 view requires information from the SalesXZ view. The SalesXZ view requires information from the InvoicesXZ view. The InvoicesXZ view requires information from the AcctAgeXZ view. The AcctAgeXZ view requires information from the ExpenseXZ table. When the July2003 view tries to retrieve information from the ProjectionsXZ table, the server first checks to see whether cross-database chaining is enabled between Database 1 and Database 2. When the July 2003 view tries to retrieve information from the ProjectionsXZ table, the server first checks to see whether cross-database chaining is enabled between Database 1 and Database 2. References: For more information about ownership chains, see “Ownership Chains”, http://go.microsoft.com/fwlink/?LinkID=127654
- Module 4: Managing Security Course 6231A On this slide, you will learn common uses of Database-Level Roles. Describe the three different scenarios listed on this slide. DBO Perhaps the most commonly used fixed database role is the dbo role. Members of the db_owner fixed database role can perform all configuration and maintenance activities on the database, and can also drop the database. This broad reaching role will ensure that members have all necessary permissions within a database but may be too far reaching depending on the data access needs of your user. Read-Only Users Frequently administrators will identify situations where users or groups can read data but not modify or delete the data. The read-only users or groups can easily be assigned to the db_datareader role. Data authors Authors are user who need read, write and delete access against tables in the database. In this situation, you need to add these users or groups to two database-level roles: db_datawriter : Members of the db_datawriter fixed database role can add, delete, or change data in all user tables. db_datareader: Members of the db_datareader fixed database role can read all data from all user tables. References: For more information about the different database-level roles, see “Database-Level Roles”, http://go.microsoft.com/fwlink/?LinkID=127643
- Module 4: Managing Security Course 6231A This is a demonstration of creating and managing SQL users and roles. In this demonstration, you will create several Windows accounts. you will create Windows groups and assign Windows account to those groups. You will create SQL Server logins and database users and roles using our newly created Windows groups and user accounts. Task 1: Create new users for Windows groups and users, and the App SQL Server login. In Object Explorer create the following new AdventureWorks2008 database users: User name: Employees Login name: NY-SQL-01\\Employees Default schema: Leave blank User name: Paul Login name: NY-SQL-01\\Paul Default schema: HumanResources User name: Susan Login name: NY-SQL-01\\Susan Default schema: dbo User name: App Login name: App Default schema: HumanResources Verify that the new database users have been created Task 2: Assign roles to users and verify users' permissions View the properties on the database user Susan. Add the database role db_backupoperator to this user. On the file menu open E:\\Mod04\\DemoCode\\TestPermissions.sql. Review the script. Replace ENTER USER NAME with App. Execute the query. Verify that query execution fails with SELECT permission denied, INSERT permission denied and EXECUTE permission denied. View the properties on the AdventureWorks2008 database user App.
- Add the db_datareader role to this user. In the query window Execute the query. In the Messages pane verify that 16 rows were returned. Verify that the INSERT and EXECUTE statements still fail. In the query window replace App with Paul. Execute the query. Verify the query fails with SELECT permission denied, INSERT permission denied and EXECUTE permission denied. In Object Explorer view the properties of the AdventureWorks2008 database user Employees. Add roles: db_datareader and db_datawritter to this user. In the query window Execute the script. Verify that the SELECT and INSERT statements succeed but that EXECUTE still fails. Task 3: Create a new customer database role and add a user to the role In Object Explorer for the AdventureWorks2008 database create a new database role, Role name: Manager. In Object Explorer, expand schemas under the AdventureWorks2008 database. View the properties of the HumanResources schema. Add: Manager to the Select Users or Roles section. Grant Manager EXECUTE permission. In Object Explorer view the properties for the AdventureWorks2008 database role: Manager. Add the database user Paul to this role. In the query window execute the TestPermissions.sql query. Verify that all statements complete successfully. When would you use roles in your environment? For example, a member of the payroll department probably views salary figures for everyone in your company, while managers might have access to salaries for members of their team. Individual employees would have no access to view any. Module 4: Managing Security Course 6231A
- Module 4: Managing Security Course 6231A
- Module 4: Managing Security Course 6231A This slide reviews encryption keys. First describe how SQL Server uses encryption keys. Then describe Asymmetric and Symmetric Keys and how they are used. Each layer of the encryption hierarchy encrypts the layer beneath it. The top layer, the Service Master Key, is encrypted with the Windows DP API. Asymmetric Keys An asymmetric key is made up of a private key and the corresponding public key. Each key can decrypt data encrypted by the other. Asymmetric encryption and decryption are relatively resource-intensive, but they provide a higher level of security than symmetric encryption. An asymmetric key can be used to encrypt a symmetric key for storage in a database. Symmetric Keys A symmetric key is one key that is used for both encryption and decryption. Encryption and decryption by using a symmetric key is fast, and suitable for routine use with sensitive data in the database. References: For more information about database encryption keys, see “SQL Server and Database Encryption Keys”, http://go.microsoft.com/fwlink/?LinkID=127664 For more information about database encryption in SQL Server, see “Database Encryption in SQL Server 2008 Enterprise Edition”, http://go.microsoft.com/fwlink/?LinkID=127641 For more information about certificates and Asymmetric keys, see “SQL Server Certificates and Asymmetric Keys”, http://go.microsoft.com/fwlink/?LinkID=127666
- Module 4: Managing Security Course 6231A On this slide, you will review Certificates. Describe what certificates are and how they are used. Also describe what kind of information that certificates contain. A public key certificate, usually just called a certificate, is a digitally-signed statement that binds the value of a public key to the identity of the person, device, or service that holds the corresponding private key. Certificates are issued and signed by a certification authority (CA). The entity that receives a certificate from a CA is the subject of that certificate. Typically, certificates contain the following information. The public key of the subject. The identifier information of the subject, such as the name and e-mail address. The validity period. This is the length of time that the certificate is considered valid. Issuer identifier information. The digital signature of the issuer. References: For more information about the encryption hierarchy, see “Encryption Hierarchy”, http://go.microsoft.com/fwlink/?LinkID=127645 For more information about database encryption in SQL Server, see “Database Encryption in SQL Server 2008 Enterprise Edition”, http://go.microsoft.com/fwlink/?LinkID=127641 For more information about certificates and Asymmetric keys, see “SQL Server Certificates and Asymmetric Keys”, http://go.microsoft.com/fwlink/?LinkID=127666
- Module 4: Managing Security Course 6231A On this slide, you do a general overview of public/private key cryptography and certificates. Describe the overall architecture and overview how it all works. The following slides will give more details on the components such as Keys and Certificates. Public Key Cryptography (PKI) is a form of message secrecy in which a user creates a public key and a private key. The private key is kept secret, whereas the public key can be distributed to others. Although the keys are mathematically related, the private key cannot be easily derived by using the public key. The public key is used to encrypt data and the private key is used to decrypt data. A message that is encrypted by using the public key can only be decrypted by using the correct private key. Since there are two different keys, these keys are asymmetric . Each layer of the encryption hierarchy encrypts the layer beneath it. The top layer, the Service Master Key, is encrypted with the Windows DP API. Certificates and asymmetric keys are both ways to use asymmetric encryption. Certificates are often used as containers for asymmetric keys because they can contain more information such as expiry dates and issuers. There is no difference between the two mechanisms for the cryptographic algorithm, and no difference in strength given the same key length. Generally, you use a certificate to encrypt other types of encryption keys in a database, or to sign code modules. Certificates and asymmetric keys can decrypt data that the other encrypts. Generally, you use asymmetric encryption to encrypt a symmetric key for storage in a database. A public key does not have a particular format like a certificate would have, and you cannot export it to a file. References: For more information about the encryption hierarchy, see “Encryption Hierarchy”, http://go.microsoft.com/fwlink/?LinkID=127645 For more information about database encryption in SQL Server, see “Database Encryption in SQL Server 2008 Enterprise Edition”, http://go.microsoft.com/fwlink/?LinkID=127641 For more information about certificates and Asymmetric keys, see “SQL Server Certificates and Asymmetric Keys”, http://go.microsoft.com/fwlink/?LinkID=127666
- Module 4: Managing Security Course 6231A On this slide, you review some scenarios in which it’s appropriate to use keys and certificates. First review the principals to follow when using algorithms. Then describe when to use certificates and when to use keys. No one algorithm is ideal for all situations, and the following general principles apply: Strong encryption generally consumes more CPU resources than weak encryption. Long keys generally yield stronger encryption than short keys. Asymmetric encryption is stronger than symmetric encryption using the same key length, but it is relatively slow. Block ciphers with long keys are stronger than stream ciphers. Long, complex passwords are stronger than short passwords. If you are encrypting lots of data, you should encrypt the data using a symmetric key, and encrypt the symmetric key with an asymmetric key. Encrypted data cannot be compressed, but compressed data can be encrypted. If you use compression, you should compress data before encrypting it. Using a Certificate in SQL Server Certificates can be used to help secure connections, in database mirroring, to sign packages and other objects, or to encrypt data or connections. Using Keys in SQL Server Asymmetric keys are used for securing symmetric keys. They can also be used for limited data encryption and to digitally sign database objects. An asymmetric key consists of a private key and a corresponding public key. Asymmetric keys can be imported from strong name key files, but they cannot be exported. They also do not have expiry options. Asymmetric keys cannot encrypt connections. References: For more information about the different encryption algorithms, see “Choosing an Encryption Algorithm”, http://go.microsoft.com/fwlink/?LinkID=127636 For more information about certificates and Asymmetric keys, see “SQL Server Certificates and Asymmetric Keys”, http://go.microsoft.com/fwlink/?LinkID=127666 For more information about how to extend database impersonation, see “Extending Database Impersonation by Using EXECUTE AS”, http://go.microsoft.com/fwlink/?LinkID=127646
- Module 4: Managing Security Course 6231A On this slide, you will review Transparent Data Encryption. First describe what Transparent Data Encryption and how it works. Then review the steps to use Transparent Data Encryption. You can take several precautions to help secure the database such as designing a secure system, encrypting confidential assets, and building a firewall around the database servers. However, in a scenario where the physical media (such as drives or backup tapes) are stolen, a malicious party can just restore or attach the database and browse the data. One solution is to encrypt the sensitive data in the database and protect the keys that are used to encrypt the data with a certificate. This prevents anyone without the keys from using the data, but this kind of protection must be planned in advance. Transparent data encryption performs real-time I/O encryption and decryption of the data and log files. The encryption uses a database encryption key (DEK), which is stored in the database boot record for availability during recovery. The DEK is secured by using a certificate stored in the master database of the server. Transparent data encryption protects data "at rest", meaning the data and log files. It provides the ability to comply with many laws, regulations, and guidelines established in various industries. This enables software developers to encrypt data by using AES and 3DES encryption algorithms without changing existing applications. To use transparent data encryption, follow these steps. Create a master key Create or obtain a certificate protected by the master key Create a database encryption key and protect it by the certificate Set the database to use encryption References: For more information about Transparent Data Encryption, see “Understanding Transparent Data Encryption http://go.microsoft.com/fwlink/?LinkID=127669
- Module 4: Managing Security Course 6231A In this demonstration, you will create the EmployeeReview table. you will create keys and a certificate. Encrypt a column of data in the EmployeeReview table using the certificate and decrypt the column using the certificate you will also see what happens when an unauthorized user attempts to access encrypted data. Task 1: Create the EmployeeReview table and assign permission to the App user. In Management Studio open the file E:\\Mod04\\DemoCode\\EncryptData.sql. In the query pane, review the script. Select the code segment below the comment 'Create Employee table and grant permissions' and click Execute. Verify that the EmployeeReview table has been created in the AdventureWorks2008 database. View the properties of the EmployeeReview table. Verify that only the App user has Insert, Select and Update permissions. Task 2: Create keys and a certificate for protecting data. In the query pane, select the code segment below the comment 'Create database master key‘. Execute the code segment Note: This statement creates a symmetric database master key for the AdventureWorks2008 databases. This key is encrypted by using the password Pa$$w0rd In the query pane, select the code segment below the comment 'Create certificate‘. Execute the code segment.
- Task 3: Encrypt and decrypt data by using the certificate In the query pane, select the code segment below the comment 'Insert encrypted data‘. Execute the code segment. In the query pane, select the code segment below the comment 'Read the decrypted data as App‘. Execute the code segment. Verify the statement 'Increasing salary to $35,000' is visible in the results pane. Task 4: Attempt to access encrypted data as an unauthorized user In the query pane, select the code segment below the comment 'Try to read data as another user‘. Execute the code segment. In the results pane verify that the code runs without error but the comments column appear blank. In the query pane, select the code segment below the comment 'Try to decrypt data as another user‘. Execute the code segment. In the results pane verify that the code fails with the message 'Cannot find the symmetric key HRKey‘. What types of organizational data might you encrypt using PKI? Payroll or other sensitive information that other users should not have access to. Module 4: Managing Security Course 6231A
- Module 4: Managing Security Course 6231A
- Begin with a discussion about what auditing is and why is it required. Discussion points include: What is Auditing? What options are available in SQL Server? Have you ever had to audit SQL Server? If so, how did you do it? If not, what do you think is the best use of auditing? SQL Server 2008 has features such as enhanced configuration and management of audits in the server, which enable organizations to meet varied compliance needs. SQL Server 2008 can also define audit specifications in each database, so audit configuration can be ported with databases. Filtering of audits to specific objects allows better performance in audit generation and flexibility in configuration. You can also set up automatic auditing by using SQL Server Audit. C2 audit mode can be configured through SQL Server Management Studio or with the c2 audit mode option in sp_configure . Selecting this option will configure the server to record both failed and successful attempts to access statements and objects. This information can help you profile system activity and track possible security policy violations. References: For more information about auditing in SQL Server, see “Auditing”, http://go.microsoft.com/fwlink/?LinkID=127634 Module 4: Managing Security Course 6231A
- Module 4: Managing Security Course 6231A On this slide, you will learn the SQL Server Profiler and its capabilities. First introduce the SQL Server Profiler describing what it is and what it can do. Then describe how the SQL Server Profiler is used. Introducing SQL Server Profiler You can capture and save data about each event to a file or table to analyze later. SQL Server Profiler shows how SQL Server resolves queries internally. This allows administrators to see exactly what Transact-SQL statements or Multi-Dimensional Expressions are submitted to the server and how the server accesses the database or cube to return result sets. Using SQL Server Profiler, you can do the following: Create a trace that is based on a reusable template Watch the trace results as the trace runs Store the trace results in a table Start, stop, pause, and modify the trace results as necessary Replay the trace results Using SQL Server Profiler If traces are becoming too large, you can filter them based on the information you want, so that only a subset of the event data is collected. Monitoring too many events adds overhead to the server and the monitoring process, and can cause the trace file or trace table to grow very large, especially when the monitoring process takes place over a long period of time. You can audit and review activity that occurred on an instance of SQL Server. This allows a security administrator to review any of the auditing events, including the success and failure of a login attempt and the success and failure of permissions in accessing statements and objects. References: For more information about SQL Server Profiler, see “Introducing SQL Server Profiler”, http://go.microsoft.com/fwlink/?LinkID=127651 For more information about how to use SQL Server Profiler, see “Using SQL Server Profiler”, http://go.microsoft.com/fwlink/?LinkID=127671 For more information about the Security Audit event category, see “Security Audit Event Category (SQL Server Profiler)”, http://go.microsoft.com/fwlink/?LinkID=127661
- Module 4: Managing Security Course 6231A On this slide, you will describe DDL triggers and discuss how they can be used. Then discuss Trigger Scope. Also discuss when to use DDL triggers. DDL Trigger Overview DDL Triggers are a special kind of trigger that fire in response to Data Definition Language (DDL) statements. They can be used to perform administrative tasks in the database such as auditing and regulating database operations. Understanding DDL Triggers DDL triggers, like regular triggers, fire stored procedures in response to an event. However, unlike DML triggers, they do not fire in response to UPDATE, INSERT, or DELETE statements on a table or view. Instead, they fire in response to a variety of DDL events. These events primarily correspond to Transact-SQL statements that start with the keywords CREATE, ALTER, and DROP. Certain system stored procedures that perform DDL-like operations can also fire DDL triggers. Understanding Trigger Scope DDL triggers can fire in response to a Transact-SQL event processed in the current database, or on the current server. The scope of the trigger depends on the event. For example, a DDL trigger created to fire in response to a CREATE_TABLE event can do so whenever a CREATE_TABLE event occurs in the database, or on the server instance. A DDL trigger created to fire in response to a CREATE_LOGIN event can do so only when a CREATE_LOGIN event occurs in the server. Database-scoped DDL triggers are stored as objects in the database in which they are created. DDL triggers can be created in the master database and behave just like those created in user-designed databases. You can obtain information about DDL triggers by querying the sys.triggers catalog view. You can query sys.triggers within the database context in which the triggers are created or by specifying the database name as an identifier, such as master.sys.triggers. Server-scoped DDL triggers are stored as objects in the master database. However, you can obtain information about server-scoped DDL triggers by querying the sys.server_triggers catalog view in any database context. How would you use DDL triggers to track changes in your organization's database? You can prevent or log changes to your database. As a DBA or database developer, it may be important to know if and when something in your database has changed. In some cases, you may even want to prevent changes by any user altogether. Reference: For more information about DDL Triggers, see “DDL Triggers”, http://go.microsoft.com/fwlink/?LinkID=127644 For more information about how DDL Triggers work, see “Understanding DDL Triggers”, http://go.microsoft.com/fwlink/?LinkID=127667 For more information about auditing in SQL Server, see “Auditing”, http://go.microsoft.com/fwlink/?LinkID=127634
- Module 4: Managing Security Course 6231A This slide will introduce SQL Server Audit. Introduce SQL Server Audit and describe what it is and then describe how it is used. Mention that it can be used through SQL Server Management Studio or with T-SQL statements. Auditing an instance of SQL Server or a SQL Server database involves tracking and logging events that occur on the system. You can use several methods of auditing for SQL Server. Beginning in SQL Server 2008 Enterprise Edition, you can also set up automatic auditing by using SQL Server Audit. SQL Server Audit You can record server audit action groups per-instance, and either database audit action groups or database audit actions per database. The audit event will occur every time that the auditable action is encountered. Using Management Studio or Transact-SQL to execute Transact-SQL DDL statements, dynamic management views and functions, or catalog views, you can create simple or complex SQL Server Audit solutions for your SQL Server environment. Before you can create a server-level audit specification you must create and configure a SQL Server Audit object that can be used for the server audit. Accomplishing this task involves using Query Editor in SQL Server Management Studio. References: For more information about SQL Server Audit, see “Understanding SQL Server Audit”, http://go.microsoft.com/fwlink/?LinkID=127668 For more information about creating and managing audits, see “Creating and Managing Audits with Transact-SQL”, http://go.microsoft.com/fwlink/?LinkID=127638 For more information about creating a server-level audit, see “How to: Create a Server-level Audit”, http://go.microsoft.com/fwlink/?LinkID=127649
- Module 4: Managing Security Course 6231A On this slide, you will learn the different types of Audit Action Groups in SQL Server. First describe what SQL Server Audit Action Groups are. Then review the three groups listed on the slide. Server-Level Audit Action Groups Server-level audit action groups are actions similar to SQL Server security audit event classes. Server-level action groups cover actions across a SQL Server instance. For example, any schema object access check in any database is recorded if the appropriate action group is added to a server audit specification. In a database audit specification, only schema object accesses in that database are recorded. Database-Level Audit Action Groups Database-Level Audit Action Groups are actions similar to SQL Server Security Audit Event classes. Audit-Level Audit Action Groups You can also audit the actions in the auditing process. This can be in the server scope or the database scope. In the database scope, it only occurs for database audit specifications. References: For more information about SQL Server Audit Action groups and Actions, see “SQL Server Audit Action Groups and Actions”, http://go.microsoft.com/fwlink/?LinkID=127665
- Module 4: Managing Security Course 6231A In this demonstration, you will create a SQL Server Audit object and define its target. you will then create and enable an audit specification, after which you will create an auditable event by inserting a record and view the details of that event in the Window Event Viewer. Task 1: Create a SQL Server Audit object and define its target . In Object Explorer, expand NY-SQL-01 | Databases | AdventureWorks2008 | Tables | Person.Person | Keys and delete FK_Person_BusinessEntity_BusinessEntityID. In Management Studio open the file E:\\Mod04\\DemoCode\\SQLAudit.sql. In the query pane, review the script. Select the code segment below the comment 'Create the SQL Server Audit object, and sent the results to the Windows Application event log' and click Execute. Task 2: Create and enable an audit specification Select the code segment below the comment 'Create the Database Audit Specification object using an Audit event for the Person.Person table and the FirstName and LastName columns' and click Execute.
- Task 3: Create an auditable event and view the event in the Windows event log Select the code segment below the comment 'Create an auditable event' and click Execute . In Windows, open the Event Viewer in Administrative Tools. Under Windows Logs view the Application log. Verify that a SQL Server audit event has been created. When might you use SQL Server Audit? For example, a database audit that will write an event to the audit log whenever the database owner for the specified table does a SELECT or INSERT on that table. In a high security environment, the Windows Security log is the appropriate location to write events that record object access. Module 4: Managing Security Course 6231A
- Module 4: Managing Security Course 6231A In this lab, the students will create logins and database users, assign permissions, and encrypt data. Exercise 1 In this exercise, students will configure the password policy and the SQL Server authentication mode, create SQL Server logins and assign server-scope permissions to those logins. Exercise 2 In this exercise, students will create new users for the Windows group and users for the HRApp SQL user. Students will assign roles to users and verify users’ permissions and create a new custom database role and add a new user to the role. Exercise 3 In this exercise, students create the EmployeeReview table and assign permissions to the HRApp user. Students will create keys and self-signed certificates for protecting data and attempt to access encrypted data as an unauthorized user. Exercise 4 In this exercise, students create a SQL Server audit by creating an audit object and defining it’s target, creating an audit specification and enabling it, creating an auditable event and review the even in the event log. Before the students begin the lab, read the scenario associated with each exercise to the class. This will reinforce the broad issue that the students are troubleshooting and will help to facilitate the lab discussion at the end of the module. Remind the students to complete the discussion questions after the last lab exercise. Note: The lab exercise answer keys are provided on the Course Companion CD. To access the answer key, click the link located at the bottom of the relevant lab exercise page.
- Module 4: Managing Security Course 6231A
- Module 4: Managing Security Course 6231A Q: What is the importance of password policies? A: Users need access to certain objects and their account gives them this access. The password helps protect these objects from others who were not meant to use that account. An effective password policy helps prevent passwords from being guessed or cracked. Q: How can server and database scope permissions be used to manage organizational access to data? A: Server-level permissions control who can manage the server itself (start, stop, add users, etc), and database permissions control who can do what on a particular database. Q: What are some of the benefits of encryption? A: Some of the benefits of transparent data encryption include searching encrypted data using either range or fuzzy searches, more secure data from unauthorized users, and data encryption. Q: How can SQL Server audits be used to make management tasks easier? A: You can track performance issues or log and prevent changes in a database, among other things. With this information you can alter you database to meet the needs of your organization.
- Review Questions Point the students to the appropriate section in the course so that they are able to answer the questions presented in this section. Question: How does SQL Server take advantage of Windows password Policy? Answer: When it is running on Windows Server 2003 or later, SQL Server can use Windows password policy mechanisms. Question: What database changes would you track using Profiler? Answer: For example, you can monitor a production environment to see which stored procedures are affecting performance by executing too slowly. Real-world Issues and Scenarios You can either discuss possible solutions for the scenarios at the end of the module or assign these scenarios as homework for the students. If you assign the scenarios as homework, you should provide some high-level hints that might help the students solve the problem stated in the scenarios. You can also do a follow-up debriefing the following day on some of the scenarios that have been assigned as homework to students. You can create high-level hints for each scenario by using the following possible solutions for the scenarios. Scenario: You want your IT department to be able to view customer data but not sensitive credit card numbers. Solution: Use transparent database encryption and only provide access to authorized parties. Scenario: You have a scenario where one group of Windows users can ADD data to a table and another group of Windows users can only EDIT and DELETE. What is a good way to leverage SQL to manage this situation? Solution: Create SQL logins for each Windows groups. Create database users for the logins and assign those users relevant permissions against the table. Module 4: Managing Security Course 6231A
- Best Practices for Supporting Users Running Applications on Windows XP Help the students understand the best practices presented in this section. Ask students to consider these best practices in the context of their own business situations. Documenting your organizations data access requirements in advance will make securing SQL Server easier. Identify groups of users by their access needs and create logins for those groups. Identify sensitive data in advance and create a encryption strategy around it. Module 4: Managing Security Course 6231A