Microsoft SQL Server 2008 R2 Unleashed- P42 potx

TABLE 12.1 Comparison of Column-Level Encryption and Transparent Data Encryption Data is encrypted on disk and backups Data level of encryp-tion Granular, at the column level Encrypts th

FIGURE 12.4 Viewing TDE properties in SSMS

FIGURE 12.3 Modifying TDE properties in SSMS

Backing up the certificate, private key, and master key for the server is relatively

straightfor-ward An example of backing up the master key is shown in the following SQL statement:

BACKUP MASTER KEY TO FILE = ‘c:\mssql2008\backup\masterkey’

ENCRYPTION BY PASSWORD = ‘somekeybackuppassword$$’

Transparent Data Encryption

Backing up the certificate and associated private key also uses the BACKUP command The

following example backs up the certificate created in Listing 12.1:

BACKUP CERTIFICATE MyCertificate TO FILE = ‘c:\mssql2008\backup\MyCertificate’

WITH PRIVATE KEY ( FILE = ‘c:\mssql2008\backup\MyCertificatePrivateKey’ ,

ENCRYPTION BY PASSWORD = ‘somecertbackuppassword$$’ )

If you want to restore a database backup on another server instance, a master key for the

server must exist If one does not exist, you can create one by using the CREATE MASTER

KEY ENCRYPTION syntax After creating the master key, you are able to create the TDE

certificate from a backup of the certificate from the original SQL Server instance, as shown

in the following example:

CREATE CERTIFICATE MyCertificate

FROM FILE = ‘c:\mssql2008\backup\MyCertificate’

WITH PRIVATE KEY (FILE = ‘c:\mssql2008\backup\MyCertificatePrivateKey’,

DECRYPTION BY PASSWORD = ‘somecertbackuppassword$$’)

After the certificate is restored on the other server instance, you can restore the encrypted

database backup At this point, the restore can be performed just as you would restore any

unencrypted database backup The restored database is also encrypted and behaves like

the original TDE database

TDE is a relatively simple and effective way to encrypt and protect your data Other

encryption methods that exist with SQL Server can protect different elements of your

database Encryption can be applied to columns of data, an entire table, as well as the

communication that occurs between databases and the clients that access them The level

of encryption and need to use it depend on the type of data you are securing

Limitations of TDE

Although TDE offers many benefits over column-level encryption, it has some of its own

limitations, which are important to consider They include

TDE is not granular like column-level encryption The entire database is encrypted,

but only on disk Sensitive data such as Social Security numbers or credit card

numbers can be seen by anyone who has permission to access those columns TDE

also does not prevent DBAs from viewing any data in the database

TDE does not protect communications between client applications and SQL Server

Network encryption methods should be used to protect sensitive data flowing over

the network

FILESTREAM data is not encrypted

When any one database on a SQL Server instance has TDE enabled, the tempdb

data-base is also automatically encrypted This can affect performance for both encrypted

and nonencrypted databases running on the same instance

TABLE 12.1 Comparison of Column-Level Encryption and Transparent Data Encryption

Data is encrypted on

disk and backups

Data level of

encryp-tion

Granular, at the column level Encrypts the entire database only

User level of

encryp-tion

Encrypted data can be restricted at the user level on a need-to-know basis

Any user with sufficient database permissions can view encrypted data

Impact on

applica-tions

Database applications need to be modified

Completely transparent to applica-tions and end users

Indexing of encrypted

data

Encrypted columns cannot be indexed

No restrictions on indexes

Performance impact May be significant depending on

the type of encryption key used

Small impact on performance (3–5%)

Databases encrypted with TDE can’t take advantage of SQL Server 2008’s new backup

compression If you want to take advantage of both backup compression and

encryption, you have to use a third-party application, such as Idera's SQL Safe

Backup or Redgate's SQL Backup, which both have the capability to both compress

and encrypt backups

Column-Level Encryption Versus Transparent Data

Encryption

So is column-level encryption or transparent data encryption the right solution for your

systems? Both column-level encryption and transparent data encryption provide a means

of obfuscating sensitive data to protect it from unauthorized access However, they do so

in different ways

TDE prevents the unauthorized access of the contents of the database files and backups,

but does not protect sensitive data within the database from being viewed by authorized

users or database administrators Column-level encryption provides more granular control

over the data being encrypted but is not transparent to your applications

Table 12.1 lists the similarities and differences between column-level encryption and TDE

For some organizations, you might want to consider implementing both column-level

encryption along with TDE for a database Although this combination is more complex to

set up and administer, it offers greater security and encryption granularity than does

Summary

access, whereas column-level encryption protects sensitive data within the database from

being accessed by authorized users, including DBAs Implementing TDE in conjunction

with cell-level encryption provides a layered approach to data security, which enhances its

effectiveness

The main disadvantage to implementing column-level encryption is that it isn’t

transpar-ent to the end-user applications In addition to requiring changes to the database schema,

it also requires changes in the applications to include the proper function calls to encrypt

and decrypt the data as it is stored and retrieved Another issue with column-level

encryp-tion is that you cannot index encrypted columns, nor can you generate statistics on the

encrypted columns This can affect query performance because search arguments that

reference encrypted columns cannot be optimized For this reason, typically only the most

sensitive columns of a table that do not need to be indexed are encrypted

Summary

Chapter 11, “Security and User Administration,” discusses methods to secure and control

the access to your SQL Server data via login and user security to prevent unauthorized

users from accessing your SQL Server instances and databases Column-level encryption, as

discussed here, takes these protections a step further by preventing authorized users, such

as your database or server administrators, from viewing sensitive data within a database

Transparent data encryption protects all your data from being accessed by unauthorized

users in the event that your database files or backups are lost or stolen

Chapter 13, “Security and Compliance,” discusses security methods available in SQL

Server and how they can be implemented to meet your security compliance requirements

It also covers the new data auditing methods you can use to track changes to your data

and database objects

This page intentionally left blank

Security and Compliance

IN THIS CHAPTER

Exposure and Risk

Across the Life Cycle

The Security Big Picture

Identity Access Management Components

Compliance and SQL Server

SQL Server Auditing

Setting Up Auditing via T-SQL

SQL Injection Is Easy to Do

As you complete what you think is your best database

design and application on the planet, you stop yourself

dead in your tracks and say, with hesitation, “What about

the security and compliance implications?” Now is not the

time to start thinking about these aspects In fact, as we

show you in this chapter, you should start considering these

issues from the beginning of the development life cycle

With the growth of software and database development in

the world, there is a rise in the demand for security best

practices to achieve the goals of creating secure software

Best practices must start from the glass and reach through

the application, to the database layer, and even to the

oper-ating system and the physical file levels Best practices are

also meant to be scrutinized for overall results on the basis

of the level of security, efficiency, and complexity they

provide How much and which best practice to use can also

be considered on the basis of confidentiality, integrity, and

availability (which is known as CIA) Software security must

be considered at many layers and is additive in nature—

each layer providing the necessary security and compliance

of one part of the bigger puzzle To get it right, you must

“design in” security from the beginning

In this chapter we discuss security aspects in conjunction

with a traditional development life cycle; this includes

aspects such as vulnerability assessments, threat modeling,

and identity management You can take many steps to

prevent SQL injection, for example, and other vulnerabilities

We also talk about compliance aspects in regards to global

and regional regulations such as the Health Insurance

Portability and Accountability Act (also known as HIPAA),

Limited Exposure (Internal/Intranet Only)

Exposable (External Internet)

Low

Sensitivity

(Public)

Low Risk Medium Risk Medium

Sensitivity

(Confidential)

Medium Risk High Risk High

Sensitivity

(Highly Confidential)

High Risk High Risk

Exposure End Points

FIGURE 13.1 The exposure endpoints “risk” by category of data/application sensitivity

the Payment Card Industry (PCI) standards, and data privacy regulations such as

Personally Identifiable Information (PII)

We also provide a simple example of using the SQL Server Auditing feature that can be

extremely useful in identifying and monitoring compliance of access and usage at the SQL

Server database or object levels And lastly, we show you how to do some malicious

damage with SQL injection We show you how to do this so that you can learn how to

prevent it But first, let’s try to better understand what exposure and risk are all about

Exposure and Risk

You must understand that security is really “risk management” or “risk mitigation.” It can

be very difficult to completely secure an application or environment However, you are

able to control or limit damage by following certain practices Your data and applications

have different levels of security requirements depending on the exposure endpoints (an

exposure endpoint is defined by who is using the application and data) Figure 13.1 shows a

simple matrix of data and application sensitivity versus the exposure endpoints of that

application By definition, the more external facing your application is (such as to the

Internet) and the higher the sensitivity of the data involved, the higher risk precautions

you have to take

Let’s say you have an internal company SQL Server–based application that has only very

low sensitivity data (public-facing data such as benefits data) You freely share this type of

data with whoever wants to see it The types of controls or rigor are likely very small for

this type of application—perhaps as simple as an integrated Active Directory with your

SQL Server and read-only access for all user roles

On the other side of the spectrum, you may have applications generating financial

trans-actions with credit card data that must have zero vulnerabilities, encrypt data across the

network, encrypt data at rest within SQL Server, and use the new SQL auditing feature for

Across the Life Cycle

A big part of the risk management aspect is understanding what the impact of this risk

would be if your system is compromised It is always best to identify this aspect up front

in some type of risk “cost” or “impact.” Many financially strong companies have gone out

of business as a result of security breaches they had not anticipated or considered It is

better to plan for such risk from the beginning

Another aspect to consider is staying compliant with data you use in nonproduction

envi-ronments Often, companies needlessly put their entire livelihood at risk by using live

data values in nonproduction environments If PII or other company-sensitive data is

available in your nonproduction environments (such as in Development, Test, and

Quality Assurance platforms), you are violating laws and regulations around the globe and

putting your company and your customers at risk You can easily employ data subsetting

and masking to your nonproduction data Putting this practice in place is a great idea

Across the Life Cycle

We introduce formal development life-cycle concepts in other chapters In those chapters,

such as Chapter 41, “A Performance and Tuning Methodology,” the emphasis is on

design-ing in performance from the beginndesign-ing A part of good design is how you have complied

with laws and regulations, how you have protected the data you access or store, how you

have secured your application and data, and how you have verified all this For these

reasons, we provide some details and describe what must be done across the development

life cycle to properly address security and compliance We term this process the “risk

miti-gation” of what you build

Figure 13.2 shows a formal waterfall development life cycle with key security and

compli-ance items identified at each relevant phase Getting into the risk mitigation business starts

by giving security and compliance the full commitment and recognition they deserve

This step starts with a clear statement of security and compliance objectives as you are

sizing up your application in the assessment phase These objectives often take the form

of stating how you will address the rules, laws, data sensitivities, access considerations,

and eventual end users (and the countries they reside in)

Next, you focus on the clear identification and specification of all security and scope of

compliance You look at the details of exactly where the compliance or security lines need

to be, determine how you must fully address them, and clearly identify which must be

adhered to for your application Often, organizations have security information analysts

and data privacy groups that contribute to this part of your development efforts They, in

turn, bring others to the table, such as legal, auditing, and even corporate

communica-tions folks

As you go into the design phase, you must complete the full analysis and design of every

security and compliance element for your application As part of this analysis and design

phase, you should start enumeration test plans that must be completely verified before

your application can be delivered to its users

Security & Compliance

Implementation Deploy

Development

Life Cycle

Phases

Construct

Design

Initiate

Risk Mitigation/Compliance

Statement of Security & Compliance Objective Security & Compliance Scope Identified Security & Compliance Analysis & Design Security & Compliance Prototyping Security & Compliance Test Plans

Security & Compliance Code/Test

Security &

Compliance Acceptance

System Test &

Acceptance Code & Test

Prototype

Identify &

Design Assessment

FIGURE 13.2 Security and compliance across the development life cycle

In the prototyping phase, you have a chance to start demonstrating how security, access,

privacy, and compliance will be addressed This phase is very important because of all the

complications, rules, laws, and issues that are at stake and must be verified We have not

run a development effort without extensive prototyping of as many security and

compli-ance tests as are humanly possible It is this risk that must be fully addressed early and

never as an afterthought!

As you fully code and test your database and application, you must never skip the

secu-rity testing and validation It is best to put these tests first in your overall test plans As

your application completely takes shape, a complete application scan for vulnerabilities

can be performed Popular tools such as AppScan are essential tools of the trade for

performing this task

Finally, as you near deployment, you should make sure all the security and compliance

acceptance tests are met You need to capture these results fully because the successful

completion of this part of acceptance testing can be shown in SOX compliance auditing

The Security Big Picture

Now, let’s turn to the bigger security and compliance picture that shows many of the

layers involved in a broader security enforcement approach Figure 13.3 shows many of

these layers, starting at the top with solid guidelines, policies, and compliance-reporting

capabilities You must start with these components to guarantee that you are aware of

what must be done and have a way to show you are doing what the policies outline

Next, you must define and create other aspects of security and compliance, such as security

Internet Protocol Network Access

Control

Disk Encryption (host) Autonomous System

File Integrity Checking (MD5, SH1, ) Policy Compliance

Distributed Denial of Service (DDoS) Access Control Lists (ACLs) Intrusion Detection/Intrusion Prevention

Database Security Auditing

Business Continuity/Disaster Recovery Security Event Management Alerts and Monitoring

Vulnerability Assessment Threat Modeling Identity Management/SSO

Security Standards & Guidelines Security Compliance Reporting

FIGURE 13.3 Security enforcement layers and components

The Security Big Picture

assessment objectives These types of components must also reach into and be enforceable

across major events such as disaster recovery (to ensure business continuity) and continue

to support what you have deployed around identity management and single sign-on

The next inner layer is where your database security is defined, along with any

database-level or database instance–database-level auditing you put into place It is also this layer where

messy things such as SQL injection can occur and Denial of Service often surfaces Getting

some type of intrusion detection and prevention scheme into place is essential Clear

access controls are also essential Later in this chapter, we describe some basic SQL

Server–based auditing at the database level Chapters 11, “Security and User

Administration,” and 12, “Data Security,” also describe much of what you must do around

overall security administration and database-level security Figure 13.3 highlights these

two critical areas

Moving further down the layers of security, you find file integrity checking, secure

Internet protocols, disk-level encryption, and other security-enhancing items They all

work together to bring you what should be a more secure (and compliant) place to deploy

your applications within

With SQL Server 2008 R2, you are essentially out-of-the-box ready to do absolutely

nothing In other words, Microsoft has taken the policy to “allow nothing,” and any

access, execution, or other action must be explicitly granted Believe it or not, this is the

right thing to do This approach ensures that all objects and accesses are explicitly

declared and, by definition, are fulfilling security and many compliance regulations