Microsoft SQL Server 2008 R2 Unleashed- P44 docx

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.. Types of Backups SQL Ser

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

SQL Injection Is Easy to Do

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

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

Database Backup and

Restore

IN THIS CHAPTER

What’s New in Database Backup and Restore

Developing a Backup and Restore Plan

Types 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

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

Types of Backups

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 Syssys-tem-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

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,

Types of Backups

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

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-Transact-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 transtrans-action 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

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

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 inseropera-tions, updates, and deleopera-tions, 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