Microsoft SQL Server 2008 R2 Unleashed- P40 potx

Column-Level Encryption Versus Transparent Data Encryption With all the concern about identity theft these days, there has been increasingly more attention paid to how all the Personally

CHAPTER 11 Security and User Administration

Summary

SQL Server 2008 continues the trend of providing more security and more flexible security

to the SQL Server database environment Several new enhancements have been added to

SQL Server 2008 that add to the slew of security changes added to SQL Server 2005 The

granularity of the permissions and the other security-related features covered in this

chapter allow you to keep your SQL Server environment safe

Chapter 12, “Data Encryption,” looks at another aspect of SQL Server that helps secure

your database environment It covers encryption methods that can be implemented to

further protect your data from unauthorized access

Data Encryption .. What’s New in Data EncryptionAn Overview of Data Security

An Overview of Data Encryption

SQL Server Key Management

Column-Level Encryption

Transparent Data Encryption

Column-Level Encryption Versus Transparent Data Encryption

With all the concern about identity theft these days,

there has been increasingly more attention paid to how all

the Personally Identifiable Information (PII) and other

sensitive information stored in databases is being protected

It is necessary to secure and protect this data to avoid any

potential liability should the PII or sensitive data fall into

the wrong hands, and in some cases, doing so may even be

required by law (for example, Health Insurance Portability

and Accountability Act, or HIPAA, requirements)

Chapter 11, “Security and User Administration,” discusses

methods to secure and control the access to your SQL

Server data via login and user security This type of security

is usually sufficient to prevent access to the data by anyone

other than properly authorized users But what if you need

to prevent authorized users, such as your database or server

administrators, from viewing sensitive data? How can you

protect sensitive data from hackers or in the event that a

database backup is stolen?

One method is to encrypt the data This chapter looks at

two methods provided in SQL Server 2008 for encrypting

data: column-level encryption and transparent data

encryp-tion (TDE) In addiencryp-tion to describing how to implement

both methods, the chapter presents the features and

limita-tions of each of these methods to help you decide which

data encryption method may help you meet your data

secu-rity needs

CHAPTER 12 Data Encryption

What’s New in Data Encryption

In SQL Server 2000 and earlier, if you wanted to encrypt data in your databases, you

usually needed to implement some form of client-side encryption SQL Server itself did

not provide any means of encrypting data at the database level, so all the encryption and

decryption occurred in the application itself This required custom-written applications to

encrypt and decrypt the data, and only those applications would be able to view the

encrypted data

SQL Server 2005 introduced the capability to perform column-level (sometimes called

cell-level) encryption This provided the capability to encrypt data within the database itself at

the column level However, this method is still not transparent to the applications and

requires changes to the database schema as well as changes to your applications and T-SQL

code to include the proper function calls to encrypt and decrypt the data as it is stored

and retrieved

SQL Server 2008 introduces a new form of database encryption: transparent data

encryp-tion TDE allows you to encrypt an entire database without affecting client applications

The purpose of TDE is to prevent scenarios in which the physical media (such as database

files or backups) containing sensitive data are stolen and then read by attaching the

data-base files or restoring the backups

NOTE

Both column-level and transparent data encryption are available only in the Enterprise

and Developer Editions of SQL Server 2008 and SQL Server 2008 R2

Another new feature in SQL Server 2008 is Extensible Key Management (EKM) EKM

enables parts of the cryptographic key hierarchy to be managed by an external source

such as Hardware Security Module (HSM), referred to as a cryptographic provider

Encryption and decryption operations using these keys are handled by the cryptographic

provider This allows for flexibility and choice in cryptographic providers as well as

common key management

An Overview of Data Security

Security is important for every product and every business By following some simple

secu-rity best practices, you can avoid many secusecu-rity vulnerabilities This section discusses some

security recommendations that you should consider for your SQL Server implementations

Securing SQL Server can be viewed as a series of steps, involving four areas: the platform,

authentication, objects (including data), and applications that access the system

The platform for SQL Server includes the physical hardware and networking systems

connecting clients to the database servers The first step in securing your SQL Server

envi-ronment is to provide sufficient physical security by limiting access to the physical server

and hardware components To enhance the physical security of the SQL Server

installa-tion, you should consider placing the server in a room accessible only by authorized

personnel, ideally a locked computer room with monitored flood detection and fire

detec-tion or suppression systems In addidetec-tion, you should physically secure your backup media

by storing it at a secure offsite location

Next, you need to ensure your system provides sufficient physical network security by

keeping unauthorized users off the network by limiting access to the network to

autho-rized users only Make sure your database servers are installed in a secure zone of your

company’s intranet behind a firewall Do not connect your SQL Servers directly to the

Internet Always make sure there is a firewall between your servers and the Internet and

set it up to block all traffic except for that which is required

Next, you need to ensure that you have secured your operating system and files SQL

Server uses operating system files for operation and data storage Be sure to restrict access

to these files to system administrators only Use the NTFS file system because it is more

stable and recoverable than FAT file systems NTFS also enables security options such as file

and directory Access Control Lists (ACLs) and Encrypting File System (EFS) file encryption

For your installed SQL Server instances, you can enhance the security of the SQL Server

installation by running your SQL Server services under service accounts granted the

minimal permissions necessary for operation (do not run under the Windows

Administrator account!) These accounts should be low-privileged Windows local user or

domain user accounts

Surface area reduction is also an important security measure Surface area reduction helps

improve security by providing fewer avenues for potential attacks on a system In addition

to running services under “least privilege” accounts, this measure also involves stopping

or disabling unused components

You should also enhance the security of the SQL Server instances through limiting the

individuals, groups, and processes granted access to SQL Server and appropriately limiting

access to the databases and objects the database contains One way is to require Windows

authentication for connections to SQL Server If you are using SQL Server authentication

as well, you should be sure to enforce password policies that require strong passwords and

password expiration for all SQL Server logins For more information on setting up SQL

Server logins and managing database users and object permissions, see Chapter 11

Even if you follow the recommendations presented here for securing your environment,

you still can be vulnerable to access control problems Encryption provides another way to

enhance security by limiting data loss even in the rare occurrence that access controls are

bypassed For example, if a malicious user hacks into the database host computer and

obtains sensitive data, such as credit card numbers, that stolen information might be

useless if it is encrypted

CHAPTER 12 Data Encryption

An Overview of Data Encryption

Encryption is the process of obfuscating data by the use of a key or password This can

make the data useless without the corresponding decryption key or password Encryption

does not solve access control problems However, it enhances security by limiting data loss

even if access controls are bypassed

Encryption is actually the conversion of readable plaintext into ciphertext, which cannot

be easily understood by unauthorized people The concrete procedure of carrying out the

encryption is called an algorithm Decryption is the process of converting ciphertext back

into its original form so it can be understood Both encryption and decryption require a

key, which must be kept secret because it enables the holder to carry out the decryption

There are two primary methods of encryption: symmetric key encryption and asymmetric

key encryption Symmetric key encryption uses the same key for both encryption and

decryption Asymmetric key encryption, also called public-key encryption, uses two

differ-ent keys for encryption and decryption, which together form a key pair The key used for

encryption is called a public key The key used for decryption is referred to as a private key.

Symmetric key encryption is inherently less secure because it uses the same key for both

encryption and decryption operations, and the exchange of data requires transfer of the

key, which introduces a potential for its compromise This can be avoided with an

asymmetric key because individuals encrypting and decrypting data have their own,

sepa-rate keys However, asymmetric encryption is based on algorithms that are more complex,

and its impact on performance is more significant, making it often unsuitable in scenarios

involving larger amounts of data However, it is possible to take advantage of the

strengths of both methods by encrypting data with a symmetric key and then protecting

the symmetric key with asymmetric encryption

One solution to the dilemma of key distribution is to use digital certificates A certificate is

a digitally signed piece of software that associates a public key with the identity of the

private key owner, assuring its authenticity There is an inherent problem with this

approach—namely, how to assure the identity of the certificate issuer To resolve this issue,

Microsoft provides a number of trusted certificate authorities (known as Trusted Root

Certification Authorities) with the operating system These certificate authorities are

responsible for verifying that organizations requesting certificates are really what they

claim to be

Typically, the algorithms used for encryption are industry standard, such as the Advanced

Encryption Standard (AES) The fact that the algorithms are published doesn’t make them

weaker, but rather helps ensure they are strong and robust Because these algorithms have

been reviewed by thousands of experts around the globe, they have stood the test of time

SQL Server 2008 allows administrators and developers to choose from among several

algo-rithms, including DES, Triple DES, TRIPLE_DES_3KEY, RC2, RC4, bit RC4, DESX,

128-bit AES, 192-128-bit AES, and 256-128-bit AES No one algorithm is ideal for all situations, and a

discussion on the merits of each is beyond the scope of this chapter However, the

follow-ing 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 slower

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

However, what really protects your data from third parties is not so much the algorithm

but the encryption key, which you must keep secure Keys must be stored securely and

made available only on a need-to-know basis Ideally, authorized people or systems should

be able to use but not necessarily have a copy of the key It’s also a security best practice to

implement key rotation, changing keys periodically in case a key has been compromised

For greater key security, you can also make use of Extensible Key Management, allowing

keys to be managed by an external source such as Hardware Security Module

SQL Server 2008 provides support for not only encryption of data, but also encryption of

user network connections and stored procedures The remainder of this chapter discusses

the two methods of data encryption, column-level encryption and transparent data

encryption Client network encryption is covered in Chapter 10, “Client Installation and

Configuration.” Encryption of stored procedure code is discussed in Chapter 28, “Creating

and Managing Stored Procedures.”

NOTE

Although encryption is a valuable tool to help ensure security, it does incur overhead

and can affect performance, and any use of encryption requires a maintenance strategy

for your passwords, keys, and certificates

Therefore, encryption should not be automatically considered for all data or

connec-tions When you are deciding whether to implement encryption, consider how users

access the data If access is over a public network, data encryption may be required to

increase data security However, if all access is via a secure intranet configuration,

encryption may not be required

This chapter describes the encryption methods available in SQL Server 2008 and SQL

Server 2008 R2 along with the pros and cons of implementing these encryption

meth-ods This information should help you to determine whether using encryption is

appro-priate for implementing your data security solutions

SQL Server Key Management

SQL Server 2008 provides rich support for various types of data encryption using

symmet-ric and asymmetsymmet-ric keys and digital certificates As an administrator, you probably need to

CHAPTER 12 Data Encryption

Service Master Key (Protected by DPAPI)

Database Master Key

Certificates Asymmetric Keys

Symmetric Keys Symmetric Keys

Symmetric Keys

Server Level Database Level

Data

Pwd

Pwd

Data

Data

Pwd

FIGURE 12.1 Key hierarchy in SQL Server 2008

protects its child keys, which in turn protect their child keys, down through the tree The

one exception is when a password is used to protect a symmetric key or certificate This is

how SQL Server lets users manage their own keys and take responsibility for keeping the

key secret

Each SQL Server instance has its service master key The service master key is the one key

that rules them all It is a symmetric key created automatically during SQL Server

installa-tion and is encrypted and protected by the Data Protecinstalla-tion API (DPAPI), which is provided

by the underlying Windows OS, using the credentials of the SQL Server service account

Protection of this key is critical because if it is compromised, an attacker can eventually

decipher every key in the server managed by SQL Server SQL Server manages the service

master key for you, although you can perform maintenance tasks on it to dump it to a file,

regenerate it, and restore it from a file However, most of the time you will not need or

want to make any of these changes to the key, although administrators are advised to back

up their service master keys in the event of key corruption

The main purpose of the server master key is to secure system data, such as passwords

used in instance-level settings such as linked servers or connection strings The service

master key is also used to secure each of the database master keys Within each database,

the database master key serves as the basis for creating certificates or asymmetric keys,

which subsequently can be applied to protect data directly or to further extend the

encryption hierarchy (for example, by creating symmetric keys) Creation, storage, and

other certificate and key management tasks can be handled internally, without resorting

Each database can have a single master key You must create a database master key

before using it by using the CREATE MASTER KEY Transact-SQL statement with a

user-supplied password:

CREATE MASTER KEY ENCRYPTION BY PASSWORD = ‘R@nD0m!T3%t’

SQL Server encrypts the database master key using a triple DES key derived from the

pass-word as well as the service master key The first copy is stored in the database, and the

second is stored in the master database Having the database master key protected by the

server master key makes it possible for SQL Server to decrypt the database master key

auto-matically when required The application or user does not need to open the master key

explicitly using the password This is a major benefit of having the keys protected in the

hierarchy

NOTE

Detaching a database with an existing master key and moving it to another server can

be an issue The problem is that the new server’s database master key is different

from that of the old server As a result, the server cannot automatically decrypt the

database master key This situation can be circumvented by opening the database

master key with the password with which it is encrypted and using the ALTER MASTER

KEY statement to encrypt it with the new database master key

When the database master key exists, developers can use it to create any of three types of

keys, depending on the type of encryption required:

Asymmetric keys

Symmetric keys

Certificates

TIP

Microsoft recommends against using certificates or asymmetric keys for encrypting

data directly Asymmetric key encryption is many times slower, and the amount of data

that you can protect using this mechanism is limited, depending on the key modulus It

is recommended that you protect certificates and asymmetric keys using a password

instead of by the database master key

Extensible Key Management

Another new feature in SQL Server 2008 that provides greater key security is Extensible

Key Management EKM enables you to manage your encryption keys via an external

provider This allows for flexibility and choice in encryption providers as well as common

key management across your enterprise

With the growing demand for regulatory compliance and concern for data privacy,

organi-zations are taking advantage of encryption as a way to provide a “defense in depth”

solu-tion As organizations increasingly use encryption and keys to secure their data, key

management becomes more complex Some high security databases use thousands of keys,

and you must employ a system to store, retire, and regenerate these keys This approach is

often impractical using only database encryption management tools As a solution,

various hardware vendors provide products to store encryption keys on hardware or

soft-ware modules These products also provide a more secure key management solution

because the encryption keys do not reside with encryption data They also move the key

management workload from SQL Server to a dedicated key management system

Extensible key management in SQL Server 2008 also supports the use of Hardware Security

Module, which enables the encryption keys used to protect your data to be stored in an

off-box device such as a smartcard, USB device, or EKM/HSM module, providing a physical

separation of keys from data SQL Server 2008 Extensible Key Management enables

third-party EKM/HSM vendors to register their modules in SQL Server When registered, SQL

Server users can use the encryption keys stored on EKM modules This enables SQL Server

to access the advanced encryption features these modules support such as bulk encryption

and decryption, and key management functions such as key aging and key rotation

SQL Server 2008 Extensible Key Management also provides data protection from database

administrators Data can be encrypted by using encryption keys that only the database

user has access to on the external EKM/HSM module

To summarize, SQL Server 2008 Extensible Key Management provides the following benefits:

An additional authorization check that enables separation of duties between

data-base administration and key management

Improved performance through hardware-based encryption/decryption rather than

software-based encryption/decryption

External encryption key generation

Physical separation of data and keys

Encryption key retrieval

External encryption key retention and encryption key rotation

Easier encryption key recovery

Manageable encryption key distribution

Secure encryption key disposal

When possible, it is highly recommended that you use EKM with both database- and

column-level encryption for more comprehensive key management and hardware-based

cryptography

CHAPTER 12 Data Encryption

Column-Level Encryption

Column-level encryption (sometimes referred to as cell-level encryption) was introduced

in Microsoft SQL Server 2005 and is still fully supported in SQL Server 2008 R2

Column-level encryption offers a more granular Column-level of encryption than TDE, allowing you to

encrypt specific data columns in the context of specific users

Column-level encryption is implemented as a series of built-in functions and a key

management hierarchy Implementing column-level encryption is a manual process that

requires a re-architecture of the application to call the encryption and decryption

func-tions explicitly when storing or retrieving data In addition, the tables must be modified

to store the encrypted data as varbinary The data is then recast back to the appropriate

data type when it is read

Column-level encryption and decryption are provided by pairs of functions that

comple-ment each other:

EncryptByCert() and DecryptByCert()—Encrypts and decrypts data using the

public key of a certificate to generate a private asymmetric key

EncryptByAsymKey() and DecryptByAsymKey()—Encrypts and decrypts data using

an asymmetric key

EncryptByKey() and DecryptByKey()—Encrypts and decrypts data by using a

symmetric key

EncryptByPassphrase() and DecryptByPassphrase()—Encrypts and decrypts

data by using a passphrase to generate a symmetric key

Before you can begin generating keys to encrypt columns, you must first make sure a

data-base master key has been created:

USE AdventureWorks2008R2;

GO

If there is no master key, create one now

IF NOT EXISTS

(SELECT * FROM sys.symmetric_keys

WHERE symmetric_key_id = 101)

CREATE MASTER KEY ENCRYPTION

BY PASSWORD = ‘Th15i$aS7riN&ofR@nD0m!T3%t’

GO

NOTE

The examples in this chapter make use of the AdventureWorks2008R2 database but

can be run in the AdventureWorks2008 database as well; however, there may be

differ-ences in the data values returned For more information on downloading and installing

the AdventureWorks databases, see the Introduction