ptg 374 CHAPTER 13 Security and Compliance /* Enable the audit. */ USE master; go ALTER SERVER AUDIT NEW_SQL_Server_Audit WITH (STATE = ON); /* Test the audit is working */ USE AdventureWorks2008R2; GO SELECT * from HumanResources.Employee; GO /* Disable the audit. */ USE master; GO ALTER SERVER AUDIT NEW_SQL_Server_Audit WITH (STATE = OFF); GO It is recommended that you create your audit specifications with scripts so that you can easily manage them and not have to re-create them via SSMS dialogs. SQL Injection Is Easy to Do As we previously stated, SQL injection is the number-one security vulnerability globally as reported and tracked by the Open Web Application Security Project (OWASP; www.owasp. org). Because of this continued vulnerability, we decided to show you how to do SQL injection. However, keep in mind that we are showing you how to do it so that you can prevent this situation from happening to you. You need to make sure you include the vulnerability checks as a part of your coding and design reviews. Then this will never happen to you. If you have a typical .NET forms application that prompts users to provide filter criteria to locate information, this is often a perfect place for hackers to add their own malicious code to do damage. Even your own employees might be hackers or want to cause harm. We call these folks “Evil SQL’ers.” The most common way SQL injection occurs is with the direct insertion of code into a variable that is part of a SQL statement. In other words, a user-defined variable is concate- nated with a partially defined SQL statement and then subsequently executed as part of the application. The hacker adds a terminating character to the first part of the input and then follows it up with his or her own destructive SQL statement. Let’s consider the following simple Contact Name search application as an example. A .NET forms application might define a variable called ContactFirstName and then prompt the end user for a value to search for any contact’s first name that begins with a set of Download from www.wowebook.com ptg 375 SQL Injection Is Easy to Do 13 characters such as “Don.” Such an operation might result in finding “Don,” “Donald,” and “Donny” matching rows. The code might look like this: var ContactFirstName; ContactFirstName = Request.form (“ContactFirstName”); var sql = “SELECT * FROM [AdventureWorks].[Person].[Contact] WHERE [FirstName] like ‘“ + ContactFirstName + “%’”; The subsequent SQL code that would be submitted to SQL Server for execution would be as follows: SELECT * FROM [AdventureWorks].[Person].[Contact] WHERE [FirstName] Like ‘Don%’; This code works perfectly. To test this code as if you are an “Evil SQL’er,” create a table named XtraContactsTable that you can pretend is your primary contacts table where all your company’s contacts are stored. Go ahead and create this empty table for this evil test. The simple CREATE state- ment could be CREATE TABLE [dbo].[XtraContactsTable] ([ContactFirstName] [nchar](10) NULL) ON [PRIMARY]; To be really evil, attempt to drop this table and cause severe damage to this company using the SQL injection method. Now, at the applications prompt for a contact first name, you, acting as the evil SQL’er, can instead type the following: Don’; drop table [dbo].[XtraContactsTable] The subsequent SQL code that is sent to SQL Server for execution is SELECT * FROM [AdventureWorks].[Person].[Contact] WHERE [FirstName] Like ‘Don%’; drop table [dbo].[XtraContactsTable] The first part of the query is executed, followed by the DROP TABLE statement. Try this with the table you just created. After you execute the entire “valid” SQL statement, you see rows returned from the first part of the query, and the drop of the XtraContactsTable is also executed. If the evil code had simply used the Employee table name or the Contact table name, all your company’s most sacred data would be gone in a flash. That is SQL injection! It is easier to do than you think. And now you know how to do it, which means you must also prevent this and other SQL injection vulnerabilities from the beginning. In this case, you should write code to reject quotation marks, specific delim- iters (such as ;), and comment characters such as - - and /* */. We have included this SQL code example on the CD with this book as well. Another popular method by Evil SQL’ers is to put a nasty piece of code into text or char data that will be stored as data in a table. When (or if) the data is ever used as part of a Download from www.wowebook.com ptg 376 CHAPTER 13 Security and Compliance FIGURE 13.12 Reprinted with permission from xkcd.com. SQL statement (and concatenated to SQL code as just demonstrated), the code in the data is executed. Pretty tricky! Sort of like a time bomb waiting to explode. NOTE For additional examples of SQL injection and SQL coding tips to help prevent SQL injec- tion attacks, see Chapter 43, “Transact-SQL Programming Guidelines, Tips, and Tricks.” Summary As stated earlier, best practices for security and compliance must start from the glass and reach through the application, to the database layer, and even to the operating system and the physical file levels. This chapter describes an orderly process to follow as you develop applications that include security and compliance reviews and add testing all along the way. You should never wait until your application is done to start checking for security vulnerabilities; verify adherence to compliance rules or regulations; or determine what data needs to be protected, encrypted, or perhaps not even stored. Taking advantage of the new SQL Server Auditing feature can be extremely useful in iden- tifying and monitoring compliance of access and usage at the SQL Server database or object levels. Now you know how to do a little damage via SQL injection. You should also know how to prevent this type of damage. Remember, software security is really risk management. It is this risk that must be analyzed thoroughly. After you analyze it, responding in a known situation is always easier. Risks can appear due to architectural problems or with holes in applications (such as with SQL injection). The main aim of soft- ware security is to just fall safely and carefully and to limit the damage. We don’t want to read about your failing in the newspaper or on Twitter. In the next chapter, you learn about database backup and restores. To fix damage caused by security issues like those described in this chapter, you may have to restore your data- base to its state before the attack occurred. We hope that this never happens to you. Download from www.wowebook.com ptg CHAPTER 14 Database Backup and Restore IN THIS CHAPTER . What’s New in Database Backup and Restore . Developing a Backup and Restore Plan . Ty pes of Backups . Recovery Models . Backup Devices . Backing Up a Database . Backing Up the Transaction Log . Backup Scenarios . Restoring Databases and Transaction Logs . Restore Scenarios . Additional Backup Considerations You need to perform database backups to protect your investment in data. Making backups may seem mundane, but consider Murphy’s Law (“If anything can go wrong, it will”) when you are considering your backup plan. For example, if you forget to add a new database to your backup plan, that database will crash. If you neglect to run a test restore of your backups, those backups will not restore properly. This type of thinking may seem a bit defeatist, but it can help you create a robust backup solution that allows you to sleep comfortably knowing you have a good plan. Fortunately, SQL Server comes with many different backup and restore options you can use to develop a robust backup plan and avoid those worst-case scenarios. This chapter covers the key considerations in developing a backup and restore plan and then covers the options available with SQL Server to implement that plan. What’s New in Database Backup and Restore The majority of the backup and restore features that existed in SQL Server 2005 still exist in SQL Server 2008. A few options, however, have been eliminated or deprecated. For example, the backup options used to truncate the transac- tion log in prior versions are no longer supported. Specifically, the NO_LOG and TRUNCATE_ONLY options have been eliminated. The alternative for performing this kind of operation is to set the database recovery model to simple. Several other deprecated features are still available in SQL Server 2008 but will be removed in a future version of SQL Download from www.wowebook.com ptg 378 CHAPTER 14 Database Backup and Restore Server. The Tape backup option is one example. The option to set a password on a backup or media-set will be removed in the next version of SQL Server. The protection provided by these passwords is weak, which is the reason they are being removed. The biggest enhancement in backup and restore is the ability to create a compressed backup. Compressed backups use less space and can be created in less time than conven- tional backups. The creation of compressed backups can be established server-wide or can be enabled on a single backup using the COMPRESSION option. This feature is available only in SQL Server 2008 Enterprise and Developer Editions. Developing a Backup and Restore Plan Developing a solid backup and restore plan for SQL Server is one of the most critical tasks an administrator performs. Simply put, if you are a database administrator (DBA) and have a significant loss of data in a database you are responsible for, your job may be on the line. You need to carefully examine the backup needs of your organization, document those needs, and deliver a plan that defines how your backup and restore plan will meet those needs. The best place to start in identifying the backup requirements is to ask the right questions. The following questions can help drive out the answers you need: . How much data loss is acceptable? For example, if you choose to do only full data- base backups each night, would it be acceptable to lose all the data added to the database during the next day? This could happen if you had a failure and had to restore to the last full backup. . What is the nature of the database? For example, is the database used for a data warehouse, or is it used for a high-volume transaction processing system? . How often does the data in the database change? Some databases may change very little or not at all during the day but sustain heavy batch updates during the evening. . What is the acceptable recovery time in the event a database must be restored from previous backups? This question is directly related to the amount of downtime acceptable for the applications using the database. . Is there a maintenance window for the application/database? The maintenance window is typically a period of time when the database or server can be taken offline. What are the exact times of the maintenance windows? . What is the size of the database(s) you need to back up? . What media is available for backup, and where is the media located? . What is the budget for database backup and recovery? If no budget has been estab- lished, the answers to some of the preceding questions drive the cost of the solution. Some of the questions that need to be asked to come up with a good backup and restore plan may raise some eyebrows. For example, you may find that the answer you get for the question “How much data loss is acceptable?” is “None!” Don’t panic. There are sensible Download from www.wowebook.com ptg 379 Types of Back ups responses for these types of answers. The reality is that you can deliver a solution that virtually eliminates the possibility of data loss—but that comes at a cost. The cost may come in the form of real dollars as well as other costs, such as performance or disk space. As with many other technical solutions, you need to consider trade-offs to come up with the right plan. NOTE Many of the questions that relate to database backup and restore are related to sys- tem backups as well. System-wide backups, which happen independently of SQL Server backups, capture all or most of the files on a server and write them to appropriate media. These server backups are often performed by DBAs, system administrators, and the like. You should consider having the person or persons responsible for the system backups present when asking the database backup and restore questions. This will help with the coordination and timing of the backups. When you have the answers to these questions, you need to document them, along with your recommended solution. You should identify any assumptions and make sure to outline any portion of the plan that has not met the requirements. The good news is that the implementation of the plan is often less difficult than coming up with the plan itself. Microsoft provides a myriad of tools to create database backups that can meet the needs of your organization. The remainder of this chapter focuses on the details required to finalize a solid backup and recovery plan. Types of Backups SQL Server offers several different types of backups you can use to restore a database to a former state. Each of these backups uses a file or set of files to capture the database state. The files are found outside the SQL Server database and can be stored on media such as tape or hard disk. As described in the following sections, these backup types are available with SQL Server 2008: . Full database backups . Differential database backups . Partial backups . Differential partial backups . File and filegroup backups . Copy-only backups . Transaction log backups 14 Download from www.wowebook.com ptg 380 CHAPTER 14 Database Backup and Restore Full Database Backups A full database backup is an all-inclusive backup that captures an entire database in one operation. This full backup can be used to restore a database to the state it was in when the database backup completed. The backup is transactionally consistent, contains the entire database structure, and contains the related data stored in these structures. As with many other backups, SQL Server allows for updates to the database while a full backup is running. It keeps track of the changes occurring during the backup by capturing a portion of the transaction log in the database backup. The backup also records the log sequence number (LSN) when the database backup is started, as well as the LSN when the database backup completes. The LSN is a unique sequential number you can use to deter- mine the order in which updates occur in the database. The LSNs recorded in the backup are used in the restore process to recover the database to a point in time that has transac- tional consistency. A full database backup is often used in conjunction with other backup types; it establishes a base for these other types if a restore operation is needed. The other backup types are discussed in the following sections, but it is important not to forget about the full backup that must be restored first in order to utilize other backup types. For example, let’s say you are making hourly transaction log backups. If the database is to be recovered using those transaction log backups, the last full database backup must be restored first, and then the subsequent log backups can be applied. Differential Database Backups Differential database backups capture changes to any data extent that happened since the last full database backup. The last full database backup is referred to as the differential base and is required to make the differential backup useful. Each data extent that is monitored consists of eight physically contiguous data pages. As changes are made to the pages in an extent, a flag is set to indicate that a change has been made to the extent. When the differential database backup is executed, only those extents that have had pages modified are written to the backup. Differential database backups can save backup space and improve the overall speed of recovery. The savings in space and time are directly related to the amount of change that occurs in the database. The amount of change in the database depends on the amount of time between differential backups. When the number of database changes since the last backup is relatively small, you achieve the best results. If, however, a significant number of changes occur to the data between differential backups, the value of this type of backup is diminished. Ultimately the number of data pages that are affected by the changes determine the number of pages that must be included in the differencial backup. The number of pages is affected by the indexing structure as well as the nature of the updates. If for example, Download from www.wowebook.com ptg 381 Types of Back ups there are many rows that are changed but those rows are all clustered on a limited number of data pages then the differencial backup will not be that large. Partial Backups Partial backups provide a means for eliminating read-only data from a backup. In some implementations, a portion of the data in a database may not change and is strictly used for inquiry. If this data is placed on a read-only filegroup, you can use partial backups to back up everything except the read-only data. This technique reduces the size of your backup and reduces the time it takes to complete the backup. The read-only filegroups should still be backed up, but this needs to occur only after the read-only data is loaded. Differential Partial Backups Differential partial backups work like differential database backups but are focused on the same type of data as partial backups. The extents that have changed in filegroups that are not read-only are captured in this type of backup. This includes the primary filegroup and any read/write filegroups defined at the time of the backup. Like differential database backups, these backups also require a differential base, but it must be a single differential base. In other words, multiple base backups that have been taken at different times for different database files will not work. You must use a single base backup that encompasses all of the database files. File and Filegroup Backups File and filegroup backups are targeted at databases that contain more than one filegroup. In these situations, the filegroup or files in the filegroups can be backed up independently. If a filegroup is backed up, all the files defined in the filegroup are backed up. File and filegroup backups are often used for larger databases where the creation time for a full database backup takes too long or the resulting backup is too large. In these situations, you can stagger the backups of the files or filegroups and write them to different locations. The main disadvantage of this type of backup is the increase in administrative overhead. Each of the files in the database must be backed up, and a complete set of these files must be retained to restore the database. For a full recovery model, the transaction log backups must also be retained. NOTE SQL Server 2008 supports file and filegroup backups for all recovery models, including simple recovery. The catch with simple recovery is that the files and filegroups are lim- ited to read-only secondary filegroups. SQL Server 2000 did not allow these types of backups with simple recovery. 14 Download from www.wowebook.com ptg 382 CHAPTER 14 Database Backup and Restore Copy-Only Backups Copy-only backups allow a backup of any type to be taken without affecting any other backups. Normally, a database backup is recorded in the database itself and is identified as part of a chain that can be used for restore. For example, if a full database backup is taken, any subsequent differential database backups use this full database backup as their base. A restore process utilizing the differential database backups would have a reference to the full database backup, and that backup would have to be available. Copy-only backups do not affect the restore chain. They are useful in situations in which you simply want to get a copy of the database for testing purposes or things of this nature. Microsoft has made it easier to make this kind of backup by adding the Copy Only Backup check box when performing a backup using SQL Server Management Studio (SSMS). In SQL Server 2005, the Copy Only Backup had to be performed via the Transact- SQL (T-SQL) BACKUP command. An example of the copy-only backup is provided later in this chapter, in the section “Backing Up a Database.” Transaction Log Backups Transaction log backups capture records written to the transaction log file(s) defined for a database. The full and bulk-logged recovery models are the only models that support transaction log backups. These models cause transaction events to be retained in the trans- action log so that they can be backed up. Simple recovery mode causes the transaction log to be truncated periodically and thus invalidates the usefulness of the transaction log backups. The transaction log backups and their strong ties to the recovery model are discussed in more detail in the next section. Recovery Models Each database has a recovery model that determines how transactions will be written to the transaction log. The recovery model you choose has a direct impact on your ability to recover from a media failure. These following three recovery models are available with SQL Server 2008: . Full recovery . Bulk-logged . Simple You set the recovery model via T-SQL or the Database Properties window in SSMS. The following example shows the T-SQL command you can use to change the AdventureWorks2008 database to the bulk-logged model: ALTER DATABASE [AdventureWorks2008] SET RECOVERY BULK_LOGGED WITH NO_WAIT Download from www.wowebook.com ptg 383 Recovery Models FIGURE 14.1 Setting the recovery model in SSMS. Figure 14.1 shows the Options page on the Database Properties window, which also allows you to select a recovery model. 14 Full Recovery The full recovery model gives you the most protection against data loss. A database set to full recovery will have all database operations written to the transactions log. These opera- tions include insertions, updates, and deletions, as well as any other statements that change the database. In addition, the full recovery model captures any database inserts that are the result of a BCP command or BULK INSERT statement. In the event of a media failure, a database that is in full recovery can be restored to the point in time at which the failure occurred. Your ability to restore to a point in time is dependent on your database backup plan. If a full database backup is available, along with the transaction log backups that occurred after the full database backup, you can recover to the point of the last transaction log backup. In addition, if your current transaction log is available, you can restore up to the point of the last committed transaction in the trans- action log. This recovery model is the most comprehensive, but in some respects, it is the most expensive. It is expensive in terms of the transaction log space needed to capture all the database operations. The space can be significant with databases that have a lot of update activity or with databases that have large bulk load operations. It is also expensive in Download from www.wowebook.com . with SQL Server to implement that plan. What’s New in Database Backup and Restore The majority of the backup and restore features that existed in SQL Server 2005 still exist in SQL Server 2008. . Enable the audit. */ USE master; go ALTER SERVER AUDIT NEW _SQL_ Server_ Audit WITH (STATE = ON); /* Test the audit is working */ USE AdventureWorks200 8R2; GO SELECT * from HumanResources.Employee;. are still available in SQL Server 2008 but will be removed in a future version of SQL Download from www.wowebook.com ptg 378 CHAPTER 14 Database Backup and Restore Server. The Tape backup