SQL Server 2008 integration guide with nShield

Database Encryption and Key Management for Microsoft SQL Server 2008

Rob Walters and Christian Kirsch

Sponsored by

Information Security Professionals Series

Database Encryption and Key Management for Microsoft SQL Server 2008 Understanding cell-level encryption and Transparent Data Encryption in Microsoft SQL Server 2008, and managing keys with hardware security modules

Rob Walters and Christian Kirsch

Copyright © 2009 by Thales e‐Security Ltd. All rights reserved.

Published by Thales e‐Security Ltd.

No parts of this publication may be reproduced, stored in a retrieval system, or transmitted

in any form or by any means, electronic, mechanical, photocopying, recording, scanning, or

otherwise, except as permitted under Section 107 or 108 of the 1976 United States Copyright

Act, without either the prior written permission of the Publisher, or authorization through

payment of the appropriate per‐copy fee of the Copyright Clearance Center, Inc., 222

Rosewood Drive, Danvers, MA 01923, (978) 750‐8400, fax (978) 646‐8600, or on the web at

www.copyright.com.

Limit of Liability/Disclaimer of Warranty: While the publisher and author have used their

best efforts in preparing this book, they make no representations or warranties with respect

to the accuracy or completeness of the contents of this book and specifically disclaim any

implied warranties of merchantability or fitness for a particular purpose. No warranty may

be created or extended by sales representatives or written sales materials. The advice and

strategies contained herein may not be suitable for your situation. Neither the publisher nor

author shall be liable for any loss of profit or other commercial damages, including but not

limited to special, incidental, consequential, or other damages.

Contents

Introduction .......................................................................................................... 5

Database encryption ........................................................................................... 7

Understanding encryption terms ................................................................... 9

Understanding key management and HSMs ......................................................................... 12

Third‐party database encryption ................................................................. 13

Microsoft SQL Server encryption .................................................................. 15

Scenario: Smart Community Bank ............................................................... 18

Cell‐level encryption ...................................................................................... 20

Encrypting keys with a password ............................................................................................ 20

Protecting keys with certificates ............................................................................................... 23

Transparent Data Encryption ....................................................................... 27

Choosing the right encryption approach ...................................................... 28

Transparency to application ......................................................................... 28

Indexing ........................................................................................................... 29

Referential integrity ....................................................................................... 29

Performance considerations .......................................................................... 30

Using Extensible Key Management to manage keys with hardware

security modules ................................................................................................ 33

Understanding HSMs .................................................................................... 34

Scalability and operational efficiency through centralized key

management .................................................................................................... 35

Key recovery and history .............................................................................. 35

Separation of duties ....................................................................................... 37

Certified security assurance .......................................................................... 37

Installing Thales HSMs with Microsoft SQL Server 2008 ......................... 39

Installing a cryptographic provider ............................................................. 39

Cryptographic views in SQL Server ............................................................ 40

Using cell‐level encryption with HSMs....................................................... 42

Using Transparent Data Encryption with HSMs ....................................... 43

Conclusion .......................................................................................................... 47

About the authors .............................................................................................. 49

Rob Walters .................................................................................................................................. 49

Christian Kirsch ........................................................................................................................... 49

Further reading .................................................................................................. 51

Index .................................................................................................................... 53

Introduction Hardly a day goes by without news about a data loss, breach, or theft

exposing sensitive information. Encryption is a powerful tool

organizations can use as part of their data protection strategy to prevent

such costly events.

Databases are full of sensitive information worth protecting. Examples

include:

Customer billing and payment data in customer relationship

management systems

Internal financial data in enterprise resource planning systems

Personal information, such as salaries, in human resources

databases

That’s why many organizations are already encrypting databases or

planning to do so in the near future. In October 2008, the market research

company Trust Catalyst published the 2008 Encryption and Key

Management Industry Benchmark Report,1 which found that over 30 percent

of organizations running Microsoft SQL Server already encrypt their

critical data; this percentage is predicted to rise to 66 percent in the next

five years. Over 75 percent of respondents either already use database

encryption or plan to use it within the next five years. Clearly, encryption

has become one of the most widely accepted solutions to data protection

challenges. 1 See http://iss.thalesgroup.com/l/program/Survey.aspx for details.

6 Database Encryption and Key Management for Microsoft SQL Server 2008

To enable organizations to protect sensitive information, the Enterprise

and Developer Editions of Microsoft SQL Server 2008 offer two levels of

native encryption functions: cell‐level encryption and Transparent Data

Encryption (TDE). In addition, a new interface in SQL Server 2008 called

Extensible Key Management (EKM) enables the database‐native

encryption to utilize hardware security modules for external key

management.

Hardware security modules, or HSMs, are devices for protecting and

managing the cryptographic keys that are required for encrypting or

signing data. HSMs can help reduce operational costs, enhance security,

and demonstrate compliance.

This book gives an introduction to database encryption in general and

to Microsoft’s SQL Server 2008 database encryption features in particular.

It also provides suggestions and considerations for implementing

encryption using HSMs.

Database encryption Database encryption has been offered by third‐party vendors for many

years, but it was only implemented as native functionality in Microsoft

SQL Server 2005. Transparent Data Encryption (TDE) and support for

hardware security modules (HSMs) were added in Windows SQL Server

2008.

These implementations have been fueled by the increasing security and

compliance pressures organizations are facing. For example, the Payment

Card Industry Data Security Standard (PCI DSS) requires that certain

information, such as the Primary Account Number and cardholder name,

be rendered unreadable.2 If organizations want to store the full

information for later use, such as recurring charges or as part of an

account profile, encryption is the only way to reverse the information from

unreadable to readable format. Other permissible methods, such as

hashing or truncation, are irreversible, so the credit card number cannot be

used for future transactions. PCI DSS applies not only to financial

institutions that issue, accept, or process credit and debit cards, but also to

retailers who accept them as a form of payment in shops or over the phone

or web.

Apart from the global PCI DSS standard, most data protection

regulations are on the national or state level, such as California Senate Bill

1386. Like many others, this regulation doesn’t mandate that data be 2 PCI DSS Requirements and Security Assessment Procedures v1.2.1, Section 3.4


encrypted, but rather states that if data is encrypted, companies need not

notify their customers about the loss of that data.

Some recent legislation takes a more proactive stance. A new

Massachusetts law requires that personally identifiable information, such

as driver license numbers, financial account numbers, and Social Security

numbers, must be encrypted on mobile devices and while being

transferred over public networks. Failure to do so can cause penalties even

if no actual data breach takes place.

Data breaches can prove very costly to organizations. The Ponemon

Institute’s 2009 US Cost of Data Breach Study3 reports that data breaches

cost organizations an average of US$202 per lost record, raising the total

cost of an average breach to US$6.6 million. The majority of these costs

come not from regulatory fines but from costs associated with contacting

each and every affected customer and the subsequent loss of confidence.

In other words, security and compliance offer substantial competitive

advantages.

Encryption is an important part of a “defense‐in‐depth” approach:

Should an organization fail to stop an attacker at the network perimeter,

the data itself is still protected because the attacker cannot read it without

the encryption key. HSMs can help protect the key material against

copying and enforce internal controls to ensure that a single rogue insider

cannot gain access to the data.

Cell‐level encryption and TDE provide integrated features that are

readily available to users of SQL Server 2008 Enterprise Edition and

Developer Edition. Organizations implementing database encryption often

prefer the native encryption functions because they avoid technical issues

that result in compatibility problems between vendors and project delays.

3 Available at www.pgp.com.

Database Encryption 9

Because SQL Server’s encryption functions are part of the feature set of the

Enterprise and Developer Editions, native encryption is also often more

cost‐effective from a licensing perspective.

Understanding encryption terms Before we go into the details of encryption in SQL Server, let’s define the

terms: Encryption is 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.

Figure 1: Basic encryption process

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.


Figure 2: Basic decryption process

Note that the process we have described is true for symmetric encryption,

which uses the same key for encryption and decryption. The encryption

and decryption process for asymmetric encryption, also called public‐key

encryption, looks slightly different because the encryption and decryption

keys are two different keys, which together form a key pair. The key used

for encryption is called a public key; the key used for decryption is called a

private key.

It is considered a best practice to use encryption algorithms that are an

industry standard, such as the Advanced Encryption Standard (AES). The

fact that the algorithms are published doesn’t make them weaker—quite

the contrary. Because these algorithms have been reviewed by thousands

of experts around the globe, they have stood the test of time. What

protects your data from third parties is not the algorithm but the key,

which you should keep secure. Your encryption key is often simply a

random number that has passed certain tests to ensure it is a good key.

The important thing to remember for all encryption algorithms is that

the security of the data relies on the security of the keys. HSMs help

protect the keys because the applications never handle the keys directly, so

they are not exposed to malicious code or rogue administrators. If an

application wants to decrypt data, it sends the ciphertext to the HSM; the


HSM decrypts the ciphertext on the HSM, using its implementation of the

algorithm, and then returns the plaintext to the application. The key itself

is never exposed to the application.

Figure 3: The application sends the ciphertext to an HSM for decryption. The HSM returns the plaintext but never exposes the key to the application, keeping the key secure.

Microsoft SQL Server’s integration of HSMs is a little more advanced

than the basic diagram above shows. For TDE, for example, the HSM can

hold an asymmetric key that in turn encrypts a database encryption key

(DEK), which in turn encrypts the data. Such a key hierarchy, often called

key wrapping, can add great flexibility to key management.

Figure 4: The concept of key wrapping: A key encrypts another key, which encrypts the actual data. Such key hierarchies are commonly used to add flexibility to key management.


Understanding key management and HSMs

Because data security depends on key security, you should carefully plan

how you manage keys, taking into account the following factors:

Separation of duties. 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. HSMs enable organizations to apply strong internal

controls to key protection. They separate system administration

from security administration because keys are no longer managed

by the applications themselves. Thales HSMs also enable

organizations to introduce dual controls to both the security

administration and the system operation. This enables an

organization to require, for example, three out of five people from a

security administration group to be present for critical

infrastructure changes.

Key rotation. It’s a security best practice to change keys periodically

in case a key has been compromised. This practice is typically called

key rotation. Section 3.6.4 of the PCI DSS requires that keys be

rotated at least annually. The standard recommends that

organizations automate such key rotation. When keys are centrally

managed by a Thales HSM, they can be rotated much more easily

than in systems where keys are distributed across dozens or even

hundreds of systems.

High availability. HSMs can help with high availability of

encrypted databases. Ensure that the HSM you’re planning to use

supports clustered and mirrored SQL Servers, and that the HSMs

themselves can be clustered for high availability.


Backup and disaster recovery. Because keys are such sensitive

pieces of information, they must be treated separately for backup

and disaster recovery. HSMs offer functionality to ensure that keys

are securely backed up and recoverable. To ensure business

continuity, HSMs can be run in clusters across different sites.

Modern HSMs simply require the copying of encrypted files to back

up and synchronize key data. This process is secure because the

keys that encrypt the files are protected by the HSM.

Key archive. Even though new data is encrypted with the new key

after a key rotation, an organization must retain copies of previous

keys to access previously encrypted data. When keys are managed

by a Thales HSM, they can be securely archived in one central

location.

Re‐keying. If a key has been breached or even potentially breached,

it must be replaced immediately. Data protected by the old key

must be decrypted and then encrypted with a new key. Thales

HSMs can help carry out this re‐keying. Note that re‐keying

introduces some difficulties in that all copies and backups of the

data should be encrypted with the new key or destroyed.

Operational efficiency. Using a Thales HSM to centralize key

management for a database server farm and other security‐critical

applications can reduce operational costs by facilitating key

operations.

Third-party database encryption Until Microsoft implemented encryption into SQL Server, organizations

had to turn to third‐party add‐ons to encrypt their databases. Problems

with these integrations often led to incompatibilities between vendors,

especially since the add‐ons didn’t always use supported interfaces.


Whenever organizations wanted to benefit from a new database version,

they had to carry out extensive testing to see if their encryption solution

was compatible. Many organizations felt locked into these vendors

because their proprietary solutions were difficult to replace.

Microsoft SQL Server encryption Microsoft SQL Server encryption overcomes the problems of third‐party

add‐ons. Encryption is provided by the database manufacturer, greatly

simplifying support cases. It’s also easier to source expertise for this more

mainstream solution, so encryption is easier and cheaper to deploy.

Integrated encryption is more future‐proof because upgrades to new

database versions are simpler. Even key management through hardware

security modules (HSMs) doesn’t lock an organization into a particular

HSM vendor to the same extent, since Microsoft offers the Extensible Key

Management (EKM) interface specifically for HSM vendors who want to

integrate with Microsoft SQL Server. Organizations also save the extra cost

of licensing a third‐party database encryption solution.

Microsoft SQL Server 2008 offers two types of native database

encryption: cell‐level encryption and Transparent Data Encryption (TDE).

Cell‐level encryption offers a granular encryption of specific data in the

context of specific users. Introduced in Microsoft SQL Server 2005, it is still

fully supported. Using this encryption requires a re‐architecture of the

application SQL queries to call the encryption and decryption functions. In

addition, the schema must be modified to store the data as varbinary and

then re‐cast back to the appropriate data type when read. The traditional

limitations of encryption are inherent in this method, as none of the

automatic query optimization techniques can be used.


SQL Server provides two ways for HSMs to interact with cell‐level

encryption. HSMs can secure the master key for all cell‐level encryption

keys. Alternatively, they can secure the encryption keys directly. These

topics will be discussed in more detail in the chapter Installing Thales

HSMs with Microsoft SQL Server 2008.

TDE encrypts the entire database and provides user‐independent access

to the database. Because it does not require changes to the database

applications, TDE is the simpler choice for bulk encryption to meet

regulatory compliance or corporate data security standards. TDE works at

the file level, like BitLocker Drive Encryption, the volume‐level encryption

introduced in Windows Vista, which also encrypts data on the hard drive.

However, BitLocker provides full‐disk encryption that is more appropriate

for businesspeople traveling with sensitive data on laptops, whereas TDE

is designed to protect data on the disk in the data center. In that sense,

TDE does not replace cell‐level encryption or BitLocker.

The encryption keys for both cell‐level encryption and TDE can be

managed by HSMs through Microsoft’s EKM interface.

Using Extensible Key Management 17

Figure 5: Cell-level encryption encrypts individual cells or groups of cells, while TDE encrypts the entire database. The encryption keys of both methods can be managed in an HSM using Microsoft’s EKM interface.

Both cell‐level encryption and TDE protect encrypted data on the disk

drive, but cell‐level encryption also provides an additional layer of user‐

based access control.

Here are some comparisons between these two alternatives, which will

be discussed in more detail:


Cell‐level encryption Transparent Data Encryption

Advantages

Data is encrypted on disk and backups

Supports HSMs

Granular control over which data is encrypted

User‐aware encryption can control access on a need‐to‐know basis

Data is encrypted on disk and backups

Supports HSMs

Encrypts the entire database

No analysis required because entire database is encrypted

No impact on indexing, primary keys, or foreign keys

Small impact on performance (~5%)

Disadvantages

Requires analysis to find sensitive data

Database applications need to be modified

Indexes, primary keys, and foreign keys cannot be encrypted

Potential impact on performance

Encryption is not user‐aware; data is open to all users who have permission to access the database

Scenario: Smart Community Bank To illustrate the concept of encryption in SQL Server 2008, let’s turn to the

fictitious Smart Community Bank, where three employees need access to

the SmartCommunityBank database: bank manager Harry, bank teller

Joe, and investment manager Sally.

To start, we’ll create a sample database and some users:

USE [master]

GO

CREATE LOGIN Harry_Login WITH PASSWORD='w9@##@3dja'

GO

CREATE LOGIN Joe_Login WITH PASSWORD=';v81@(34319d'

GO

CREATE LOGIN Sally_Login WITH PASSWORD='cvbe4(#@1!!'

GO

CREATE DATABASE [SmartCommunityBank]

GO


USE [SmartCommunityBank]

GO

CREATE USER BankManager_Harry_User FOR LOGIN Harry_Login

GO

CREATE USER Joe_User FOR LOGIN Joe_Login

GO

CREATE USER Sally_User FOR LOGIN Sally_Login

GO

CREATE TABLE Customers

(Customer_ID INT PRIMARY KEY,

First_Name VARCHAR(50) NOT NULL,

Last_Name VARCHAR(50) NOT NULL,

Birthdate VARBINARY(100) NULL,

Social_Security_Number VARBINARY(100) NULL,

Revenue_Generated VARBINARY(100) NULL)

GO

GRANT SELECT, INSERT, UPDATE, DELETE ON Customers TO

BankManager_Harry_User

GO

GRANT SELECT, INSERT, UPDATE, DELETE ON Customers TO Joe_User

GO

GRANT SELECT, INSERT, UPDATE, DELETE ON Customers TO Sally_User

GO

The column Customer_ID contain a customer identifier, and the

columns First_Name, Last_Name, Birthdate, and

Social_Security_Number contain information about the customer.

The column Revenue_Generated is used by investment managers to

determine how much money a given customer has generated for the bank

through interest and investments.

Many of the steps shown in this e-book as Transact-SQL (T-SQL)

statements can also be carried out using the Microsoft SQL Server

Management Studio. Please refer to “Integration Guide: Database

Security Option Pack for SQL Server 2008” on the Thales website

(www.thalesgroup.com/iss).


Cell-level encryption Microsoft SQL Server offers the ability to encrypt cells, providing control

over data protection.

SQL Server handles all cell‐level encrypted data as binary data. In the

previous CREATE TABLE statement, the columns Birthdate,

Social_Security_Number, and Revenue_Generated were

VARBINARY.

To see how to store and retrieve encrypted data, let’s assume that Harry

wants to ensure that only he can see certain customer data.

Encrypting keys with a password

In the previous section, we gave users access to the Customer table. We

will now use the CREATE SYMMETRIC KEY T‐SQL statement to create a

symmetric key that will be used to encrypt the data:

CREATE SYMMETRIC KEY BankManager_Harry_User_Key

AUTHORIZATION BankManager_Harry_User

WITH ALGORITHM=AES_256

ENCRYPTION BY PASSWORD='ThisBankIsSmart!'

GO

The AUTHORIZATION parameter describes the key owner, the database

user BankManager_Harry_User.

SQL Server offers several algorithms for encryption. The authors

recommend using AES 256), which offers a high level of security

combined with good performance.

Cell-level encryption protects specific cells and makes the data

available in the context of certain users. However, cell-level

encryption is not transparent—it requires changes to the SQL

queries.


SQL Server requires the user to specify a protection method before

generating the key because leaving keys on the database server as

plaintext would defeat the purpose of encryption. In this example, we are

using a password, which we’ll have to enter every time we use the key.

A list of encryption keys is visible in SQL Server Management Studio

under the Security node of a specific database. The catalog view

Sys.symmetric_keys also returns a list of symmetric keys, their

encryption algorithms, and other useful information.

The function for encrypting plain text with a symmetric key is called

EncryptByKey, which we’ll use to insert data into our table:

EXECUTE AS USER='BankManager_Harry_User'

GO

OPEN SYMMETRIC KEY [BankManager_Harry_User_Key] DECRYPTION BY

PASSWORD='ThisBankIsSmart!'

GO

INSERT INTO Customers VALUES (1,'Howard','Walters',

EncryptByKey(Key_GUID('BankManager_Harry_User_Key'),'1/12/1954'

),

EncryptByKey(Key_GUID('BankManager_Harry_User_Key'),'042-32-

1324'),null)

INSERT INTO Customers VALUES (2,'Donald','Kirsch',

EncryptByKey(Key_GUID('BankManager_Harry_User_Key'),'6/14/1946'

),


1214'),null)

INSERT INTO Customers VALUES (3,'Bill','Doe',

EncryptByKey(Key_GUID('BankManager_Harry_User_Key'),'10/28/1955

'),


1354'),null)

CLOSE SYMMETRIC KEY [BankManager_Harry_User_Key];GO


The EXECUTE AS statement allows system administrators or users with

IMPERSONATE permissions the ability to change the execution context of

the current connection. To simulate the BankManager_Harry_User,

we’ll issue the EXECUTE AS statement to support the script. Normally, the

execution context would be set by the logged‐on user.

SQL Server must have the key in memory to perform encryption or

decryption.4 The OPEN SYMMETRIC KEY statement opens the key and

places it in memory. Notice the CLOSE SYMMETRIC KEY statement at the

end of the script, which releases the key from memory. The key is not

opened and closed for every cryptographic operation, because opening the

key requires permission checks and other operations that would hinder

performance.

As parameters, the encryption function EncryptByKey requires the

GUID (Global Unique Identifier) of an open key and the plaintext that you

wish to encrypt. You can use the function KEY_GUID to obtain a key GUID

instead of having to type it out. The EncryptByKey function returns the

encrypted binary data.

At this point if Joe, as an unprivileged user, queried the customer table,

he would see only encrypted data:

SELECT Last_Name, Birthdate, Social_Security_Number FROM

Customers

Last_Name birthdate social_security_number

Walters 0x003CF…833AAA 0x003CF…B7EA5D

Kirsch 0x003CF…4090220 0x003CF…FD11797

Doe 0x003CF…D16B04 0x003CF…B84912

You can issue the following statements to decrypt the data:

4 This is true only for host‐side asymmetric keys, host‐side symmetric keys, and HSM‐

wrapped symmetric keys—not for symmetric or asymmetric keys that are protected by an HSM.




GO

SELECT Customer_ID,first_name + ' ' + Last_Name AS ‘Name’,

CONVERT(VARCHAR,DecryptByKey(birthdate)) as 'Date of birth',

CONVERT(VARCHAR,DecryptByKey(social_security_number)) as

'Social Security Number'

FROM Customers

GO

CLOSE SYMMETRIC KEY [BankManager_Harry_User_Key]; GO

These statements will return our original table with the date of birth and

Social Security number decrypted, as shown below:

Customer_ID Last_Name Date of birth Social Security Number

1 Walters 1/12/1954 042-32-1324

2 Kirsch 8/30/1974 133-04-1214

3 Doe 10/28/1955 533-12-1354

The DecryptByKey function doesn’t require specifying a key because

the key’s thumbprint is stored within the encrypted data header. As long

as the key has been opened and is therefore in memory, SQL Server can

use it automatically.

Using a password to protect keys is not a recommended best practice

since it encourages risky behavior, such as storing passwords in clear

text within stored procedures and script files.

Protecting keys with certificates

In the previous section we encrypted data and protected the symmetric

key using a password. Although this is a perfectly acceptable way of

protecting the key, you have to specify the password each time you want

to access encrypted data. As a result, the password may end up in a script


file or stored procedure in clear text, which defeats the purpose of

encryption. Certificates are a better alternative to protecting keys since

users do not need to remember passwords to use them. Permission to use

a certificate is explicitly granted by the system administrator to the user.

Certificates used within SQL Server follow the X.509 standard and

support X.509 V1 fields. SQL Server allows users to import certificates

created from another certificate authority. However, be aware that SQL

Server does not check the certificate expiration date or whether the

certificate came from a trusted certificate authority.

While the key is encrypted with the certificate, which contains the

public portion of an asymmetric key pair, the decryption requires the

private key. Private keys can be protected using a password or a database

master key.

Figure 6: When you’re encrypting cell-level encrypted keys with a certificate, you can protect the private key portion of this certificate with either a database master key or a password. The certificate is then used to protect the symmetric key for cell-level encryption.

With the following commands, you can create a database master key

that protects keys without passwords:


GO

CREATE MASTER KEY

ENCRYPTION BY PASSWORD = 'Some!@Complex*@(39'

GO


The password used in the CREATE MASTER KEY statement is used to

encrypt the database master key; this password‐encrypted version is used

for disaster recovery or if the database is moved to a different instance.

When the database master key is created, a copy of this key is encrypted

using the service master key. This enables the SQL Server service account

to automatically decrypt the key for the requesting user (provided the user

has the appropriate permissions).

Now that you have created the database master key within the

SmartCommunityBank database, you can create a certificate that will be

used to protect the symmetric key.

If you have been executing the script code throughout this book, your

current connection to SQL Server will be under the context of

BankManager_Harry_User since we issued an EXECUTE AS statement

previously. At this point, you need to change the connection context to

that of the sysadmin. You can do so via a REVERT statement or by

opening a new query against SQL Server. To revert the current connection

context back to sysadmin using the REVERT statement, execute the

following code:

REVERT

GO

To create a certificate whose private key is protected by the database

master key, execute the following code:

CREATE CERTIFICATE BankManagersCert

AUTHORIZATION BankManager_Harry_User

WITH SUBJECT=’Bank manager’’s certificate’

GO


BankManager_Harry_User’s certificate mitigates the issue of

password management because the symmetric key is now protected by a

certificate rather than a password. In the next sample code, we’ll change

the symmetric key’s protection from a password to a certificate by opening

the key, adding the certificate protection, and removing the password

protection. This process ensures that the symmetric key is never stored in

clear text at any time.



GO

ALTER SYMMETRIC KEY BankManager_Harry_User_Key

ADD ENCRYPTION BY CERTIFICATE BankManagersCert

GO

ALTER SYMMETRIC KEY BankManager_Harry_User_Key

DROP ENCRYPTION BY PASSWORD='ThisBankIsSmart!'

GO

CLOSE SYMMETRIC KEY [BankManager_Harry_User_Key];

GO

Because the key is now protected with a certificate, Harry no longer

needs to specify a password to open the key. To confirm this, we change

the context to BankManager_Harry_User with the EXECUTE AS

statement:

EXECUTE AS USER=’BankManager_Harry_User’

GO


GO

OPEN SYMMETRIC KEY [BankManager_User_Key] DECRYPTION BY

CERTIFICATE BankManagersCert

GO

SELECT Customer_ID,First_Name + ' ' + Last_Name AS ‘Name’,

CONVERT(VARCHAR,DecryptByKey(Birthdate)) as 'Date of birth',

CONVERT(VARCHAR,DecryptByKey(Social_Security_Number)) as

'Social Security Number'

FROM Customers

GO


CLOSE SYMMETRIC KEY [BankManager_Harry_User_Key];GO

Transparent Data Encryption Now let’s enable TDE on the SmartCommunityBank database:

USE master;

GO

CREATE MASTER KEY ENCRYPTION BY PASSWORD = 'EOhnDGS6!7JKv';

GO

CREATE CERTIFICATE MyServerCert WITH SUBJECT = 'My DEK

Certificate';

GO

USE SmartCommunityBank

GO

CREATE DATABASE ENCRYPTION KEY

WITH ALGORITHM = AES_128

ENCRYPTION BY SERVER CERTIFICATE MyServerCert

GO

ALTER DATABASE SmartCommunityBank SET ENCRYPTION ON;

GO

Note: The impact of TDE on performance is usually small and can

depend on server hardware and many other factors. You should test

performance during development before pushing out TDE to a production

environment.

You can measure performance by capturing traces via SQL Server

Profiler, a tool provided with SQL Server 2008. It can be used to display

CPU, I/O, and duration of SQL Server T‐SQL statements being processed

on a SQL Server instance. You can also use one of several third‐party

products to measure database performance.

Choosing the right encryption approach Is cell‐level encryption or Transparent Data Encryption (TDE) the right

technology for your systems?

You should first ask yourself: Have you classified your data so that you

know where your sensitive data resides, including all of its copies? This

question is not as trivial as it may seem.

Transparency to application An important aspect of introducing encryption to an organization is the

impact on existing systems and the costs associated with the

implementation. In this respect, cell‐level encryption and TDE have

important differences.

Cell‐level encryption requires that the SQL statements used to access

sensitive information in the database be modified. In other words,

companies must change the code of existing applications in order to

leverage SQL Server’s cell‐level encryption features. At best, this rework of

code can be tedious. At worst, it may not be an option because the

application’s code cannot be altered.

By contrast, TDE does not require any changes to the SQL queries and

does not require additional or different credentials to be passed to the

database.


Indexing Before choosing your encryption approach, you should consider whether

encrypted data needs to be indexed. Cell‐level encryption stores encrypted

data as varbinary, a data type that doesn’t support indexing.

There are some workarounds you may want to consider. For example,

create a new identifier column in place of the sensitive column. This

allows you to index and keep the sensitive data encrypted. For example, if

the Social Security number was used as an identifier to the database

application and we needed to encrypt this sensitive data, we could

introduce a new column called customer_id that would be used to

represent the customer instead. Note that this kind of application

modification is sometimes impossible.

Enabling TDE does not affect the user experience and thus carries no

restrictions on the use of indexes on data within a TDE‐encrypted

database.

Referential integrity Relational databases typically have references between tables that, for

example, link a customer to one or more credit card numbers. The

references are established using primary keys and foreign keys, the word keys

Cell-level encryption provides an additional layer of data protection

beyond permissions. It may require database applications to be

modified. TDE does not distinguish between users and is fully

transparent to the application. Its primary benefit is protecting

information in storage on the disk.

TDE fully supports indexes since the database engine has full access

to plaintext data. With cell-level encryption, data is decrypted only

when this is explicitly requested and authorized.


being used in the sense of a unique identifier, not in the sense of a

cryptographic key. Referential integrity describes the state of a relational

database where these references between tables are intact.

Because cell‐level encryption turns all values into binary values, they

cannot be referenced. Therefore, cell‐level encryption imposes restrictions

on referential integrity. If encrypted data is kept out of the primary and

foreign key columns, this is not a problem.

Personally identifiable unique numbers, such as Social Security

numbers or account numbers, have been popular ways to identify data

sets. To encrypt such databases with cell‐level encryption, organizations

can change the foreign keys to a random number or a hash value of the

confidential number. If you don’t need the granular control of cell‐level

encryption, you should use TDE, which does not have these restrictions.

Performance considerations Many database administrators are concerned about how data encryption

impacts performance. With any form of encryption, extra CPU cycles are

needed since encryption algorithms are essentially mathematical

equations. Each algorithm can require more or less CPU depending on its

complexity. When working with cell‐level encryption, CPU load will

increase anytime you use any of the encryption functions, such as

EncryptByKey or DecryptByKey. The actual disk I/O is not affected,

because the SQL Server is just managing varbinary data as opposed to the

native data type of the original plaintext value.

Cell-level encryption is not recommended for data involved in primary

and foreign key relationships. Transparent Data Encryption has no

side effects on references inside the database.


TDE adds CPU load and reduces query performance because SQL

Server needs to process every page that is written to or read from the disk,

both for the TDE‐enabled database and TempDB. Because the

encryption/decryption occurs only at file I/O time, the performance hit is

minimal—about 5 percent. TempDB is automatically encrypted when any

other database is encrypted with TDE.

Since performance can differ greatly depending on applications,

implementation, usage and hardware, you should nevertheless carry out

tests in a test environment before rolling out encryption to your

production systems.

Using Extensible Key Management to manage keys with hardware security modules In the chapter Understanding key management and HSMs, we discussed the

importance of key management in fulfilling requirements including

controlling access to, re‐keying, and archiving keys. Carefully planned key

management can improve operational efficiencies, reduce the total cost of

managing the database, enhance security, and facilitate compliance. To

facilitate key management, Microsoft has created an interface called

Extensible Key Management,5 or EKM, that supports external key

management with hardware security modules (HSMs).

5 For more information, see http://msdn.microsoft.com/en‐us/library/bb895340.aspx.


Figure 7: Cryptographic architecture showing the relationships among databases, EKM, and the HSM.

Understanding HSMs An HSM is a physical device that provides cryptographic services to an

infrastructure without ever disclosing the keys it manages.

HSMs are available as plug‐in cards that provide functionality for one

server or as network‐attached devices that serve an entire infrastructure.

Most organizations managing keys for database encryption will choose

network‐attached variants to take full advantage of the operational

benefits of managing all encryption keys with one system. To provide high

availability, HSMs can be clustered. They also feature dual, hot‐swap

power supplies. Thales HSMs also support SQL Server’s failover

clustering as well as mirrored SQL Servers.


Figure 8: Thales HSMs in the nCipher product line can be dedicated to one server or provide cryptographic services to an entire infrastructure. Thales nShield PCI Express module (left) is for use in single servers. The network-attached Thales nShield Connect (right) features dual, hot-swap power supplies and supports up to 100 clients.

Scalability and operational efficiency through centralized key management Organizations can greatly benefit from a centralization of their key

management. Managing all keys from one location rather than on many

distributed servers makes it much easier to rotate or archive keys.

Managing database encryption keys centrally, across database servers

and vendors, also greatly increases scalability to an enterprise level. Thales

HSMs can be clustered, and some feature dual power supplies to ensure

high availability. Unlike alternative solutions, Thales HSMs also support

integration with SQL Server failover clustering and SQL server mirroring.

These scalability advantages yield great operational efficiencies that

result in much lower cost of operations. For example, Thales HSMs can

facilitate the key rotation of dozens or even hundreds of servers, which is

much faster and requires fewer personnel than individually changing keys

on those servers.

Key recovery and history Organizations must plan for disasters in order to ensure business

continuity. If data is encrypted, the encryption keys must be a part of the


disaster recovery strategy. An efficient, secure backup of the keys is

essential.

Thales HSMs use a key management concept called Security World that

makes key recovery of failed systems very efficient without compromising

security.

When an organization initializes a Thales HSM, the device generates a

module key, which is split and backed up on smart cards called

administrator cards. To ensure a proper separation of duties, a quorum of

k administrators out of n total administrators holding a card must convene

to either recover this key or make security‐critical changes to the

infrastructure, for example adding an HSM to a cluster.

When the organization then adds application keys to be protected by

the HSM, these application keys are encrypted with the module key and

saved in a Security World file on a regular file server, which can be backed

up automatically using the organization’s regular backup mechanisms.

In the case of a disaster, the organization needs only a quorum of the

administrator cards and a copy of the Security World files to recover the

key material on a new Thales HSM.

Because the application keys are effectively stored in encrypted form in

the Security World files on the file system, they are limited in number and

size not by the HSM hardware but only by the hard disk of the file server,

giving the organization inexpensive and virtually unlimited storage space.

This becomes especially important as the organization rotates keys

periodically, because historic keys of stored data will have to be archived

in the HSM to enable the organization to read historic data.


Separation of duties Laws and regulations often require a separation of duties to carry out

security‐sensitive tasks. The provision of such internal controls can

prevent access to data by a rogue administrator or developer.

Since both the keys and data are necessary to retrieve encrypted

information, access to these should be controlled separately. Organizations

should store the encryption keys in an HSM, protecting the database keys

and storing them separate from the data. The database and HSM

administration should be kept separate or require a multi‐person control

for administrators to enhance the separation of duties.

With Thales HSMs, the SQL Server encryption keys can optionally be

protected by an operator card, which must be present in the HSM to access

the database. If the SQL Servers need to be accessed for service by a

technician, the operator can temporarily be removed to ensure that the

technician doesn’t have access to sensitive data.

Organizations must often show separation of duties and multi‐person

controls to demonstrate sufficient internal controls to auditors. Because an

HSM can clearly demonstrate this, it is considered a best practice by

auditors.

Certified security assurance Encryption key protection is an important issue to solve in every data

protection project. While software can provide a good level of protection,

dedicated hardware solutions can greatly increase the security assurance

level.

HSMs are designed from the ground up to avoid ever disclosing

cryptographic keys outside a certified hardware boundary. Instead, they

process all cryptographic operations directly on tamper‐resistant

hardware. Security‐critical keys never leave the HSM. Recognized as a


security best practice, HSMs provide the highest level of security,

protecting keys even if the operating system or application is breached.

Many security‐conscious organizations, especially large enterprises and

government agencies, have to follow internal or external regulations

demanding FIPS 140‐2 or Common Criteria compliance, which can easily

be achieved by selecting an HSM with these certifications. The key

management of Thales HSMs complies with both FIPS 140‐2 Level 3 and

Common Criteria EAL4+.

Installing Thales HSMs with Microsoft SQL Server 2008 Using a hardware security module (HSM) enhances the security of your

SQL Server by storing and centralizing the management of encryption

keys outside of SQL Server. To instruct SQL Server to use an HSM, you

must create a reference to a cryptographic provider. In the next section,

you will learn how to install a provider in SQL Server using Thales

nShield Connect, an enterprise‐level HSM for medium‐sized deployments,

as an example. The integration of other Thales HSMs is very similar.

Installing a cryptographic provider Before integrating SQL Server, you must configure Security World on

nShield Connect and install the Database Security Option Pack from

Thales, an optional component for Thales HSMs that connects the HSM

with Microsoft’s Extensible Key Management (EKM) interface. Please refer

to the Thales product documentation of your particular HSM model for

guidance on how to carry out these steps.

After you have completed these steps, enable the EKM Provider on SQL

Server with the following Transact‐SQL (T‐SQL) statement:

sp_configure 'show advanced options', 1;

RECONFIGURE;

GO

sp_configure 'EKM provider enabled', 1;

RECONFIGURE;


Use the statement CREATE CRYPTOGRAPHIC PROVIDER to specify

the DLL (dynamic link library):

CREATE CRYPTOGRAPHIC PROVIDER ThalesnShieldConnect FROM FILE =

'C:\Program Files\nCipher\nfast\bin\NCSQLEKM32.dll';

SQL Server requires credentials to connect to the HSM, which we need

to set up:

CREATE CREDENTIAL nShieldConnectloginCredential WITH IDENTITY =

'OCS', SECRET = 'pin'

FOR CRYPTOGRAPHIC PROVIDER ThalesnShieldConnect;

The parameters in this statement are the name of the HSM’s Operator

Card Set (OCS) and its password.

We can map SQL Server logins to the credential to enable the respective

users to use the keys on the HSM:

ALTER LOGIN Harry_Login ADD CREDENTIAL

nShieldConnectloginCredential;

User Harry now has access to the credential and can therefore access the

keys on the HSMs, which give him access to the data.

Cryptographic views in SQL Server SQL Server contains numerous catalog views and dynamic management

views (DMVs) providing detailed reports that help you manage

cryptographic providers. The catalog view sys.cryptographic_

providers shows all the providers that are installed on SQL Server:

SELECT * FROM sys.cryptographic_providers;

Installing Thales HSMs with Microsoft SQL Server 2008 41

This catalog view displays the provider_id for each cryptographic

provider. Some functions6 require you to pass the provider_id as a

parameter.

The sys.dm_cryptographic_provider_properties dynamic

management view shows what functions the HSM supports, such as the

authentication mode and storage of symmetric and asymmetric keys:

SELECT * FROM sys.dm_cryptographic_provider_properties;

While catalog views show static information about objects in SQL

Server, DMVs display run‐time information. The DMV for cryptographic

provider algorithms shows the current algorithms available for use by the

provider:

SELECT * FROM

sys.dm_cryptographic_provider_algorithms(provider_id)

Enter the provider_id that was returned from the previous

sys.cryptographic_providers catalog view. Algorithms returned

by this function include DES, Triple_DES, AES_128, AES_192,

AES_256, RSA_512, RSA_1024, and RSA_2048.

Alternatively, you can use the following T‐SQL script, which does not

require you to obtain the provider_id beforehand. The script is as

follows:

DECLARE @ProviderId int;

SET @ProviderId = (SELECT TOP(1) provider_id FROM

sys.dm_cryptographic_provider_properties

WHERE friendly_name LIKE 'nCipher SQLEKM provider');

SELECT * FROM

sys.dm_cryptographic_provider_algorithms(@ProviderId);

6 For example, sys.dm_cryptographic_provider_algorithms


GO

Using cell-level encryption with HSMs We are now ready to start creating keys on the HSM. Let’s go back to our

scenario at Smart Community Bank.

To create a symmetric key, use the same CREATE SYMMETRIC KEY T‐

SQL statement but specify the cryptographic provider as

ThalesnShieldConnect, which we previously defined:

CREATE SYMMETRIC KEY skeyCustomer FROM PROVIDER Thales

nShieldConnect WITH PROVIDER_KEY_NAME='skeySCBProvider',

CREATION_DISPOSITION = CREATE_NEW, ALGORITHM=AES_128;

The symmetric key is called skeyCustomer, and skeySCBProvider

is the name of the key that will be used on the HSM itself. To use this new

symmetric key to encrypt a cell of data within a column, use the function

EncryptByKey:

INSERT INTO Customers VALUES (4,'Rob','Walters',

EncryptByKey(Key_GUID('skeyCustomer'),'8/4/1961')

In this example, we’re using the HSM as the cryptographic provider

instead of the native SQL Server key management. Therefore, you do not

need to issue OPEN and CLOSE KEY statements, as these actions are

performed automatically. This is the case because we are accessing the key

directly stored in the HSM, not using the HSM to wrap a key stored locally

in the SQL database.

The procedure for decrypting data with HSMs is similar to the process

without, except we do not have to explicitly open the key. Here is how you

retrieve the customer list:


SELECT Customer_ID,First_Name + ' ' + Last_Name AS ‘Name’,

CONVERT(VARCHAR,DecryptByKey(Birthdate)) as 'Date of birth'

FROM Customers

Figure 9: HSM use-case scenario for cell-level encryption in SQL Server.

Using Transparent Data Encryption with HSMs To refresh our memory, we already created a symmetric key called the

database encryption key (DEK), which encrypts and decrypts the data

pages. The DEK is protected by a certificate in the master database. This

certificate is protected by the database master key within the master

database. To leverage an HSM in a TDE scenario, we want to protect the

DEK with an asymmetric key defined within the HSM.

Figure 10: HSM protecting the database encryption key


An asymmetric key is similar to a certificate, but it refers only to the

public/private key pair and not the digitally signed meta information of a

certificate.

SQL Server cannot access the database until it has authenticated to the

HSM, so you need to create a credential that will be used to connect to the

HSM:

CREATE CREDENTIAL Thales nShieldConnect_tde_credential

WITH IDENTITY = 'OCS name',

SECRET = 'OCS password'

FOR CRYPTOGRAPHIC PROVIDER ThalesnShieldConnect

Next, you need an asymmetric key that will be used to protect the DEK.

CREATE ASYMMETRIC KEY HSM_AsymKey

FROM PROVIDER ThalesnShieldConnect

WITH

ALGORITHM = RSA_2048,

CREATION_DISPOSITION = CREATE_NEW,

PROVIDER_KEY_NAME = 'key4TDE_SmartCommunityBank'

The asymmetric key will be mapped to a login that provides a principal

context within SQL Server but that cannot be used to log into SQL as a

regular user:

CREATE LOGIN ThalesnShieldConnect_Login

FROM ASYMMETRIC KEY HSM_AsymKey;

GO

ALTER LOGIN ThalesnShieldConnect _Login

ADD CREDENTIAL ThalesnShieldConnnect_tde_credential;

GO

Now you are ready to enable TDE:

USE SmartCommunityBank


GO

CREATE DATABASE ENCRYPTION KEY

WITH ALGORITHM = AES_256

ENCRYPTION BY SERVER ASYMMETRIC KEY HSM_AsymKey

GO

ALTER DATABASE SmartCommunityBank SET ENCRYPTION ON;

GO

Using an HSM with TDE provides an added layer of protection because

the asymmetric key protecting the DEK is stored within the HSM, not

within SQL Server. When SQL Server attaches the database upon server

startup, it loads the DEK into memory. Each subsequent access to the

database does not create any more access to the HSM. Thus, using TDE

protected by an HSM entails only a negligible performance hit.

Conclusion Large organizations store the majority of their sensitive data in databases.

Unlike previous approaches to database encryption, which did not

provide a streamlined solution for the customer, Microsoft’s recent SQL

Server 2008 release features database encryption that is largely transparent

to database applications and therefore much easier to implement.

Organizations around the world facing increasing compliance pressures

have welcomed these new technologies, especially because laws and

regulations acknowledge encryption as a best practice for data privacy.

Once the right approach has been chosen, key management is the last

piece of the puzzle to ensure the success of a database encryption solution.

Hardware security modules (HSMs) are a central part of this and provide

operational, security, and compliance benefits.

HSMs reduce operational costs by centralizing all keys and their

management into one device. They also add scalability by managing up to

hundreds of databases at once and offer short‐ and long‐term recovery of

data.

HSMs also increase the security of a solution by protecting the master

keys with hardware. They add advanced internal controls, such as

separation of duties and dual control, to security‐sensitive tasks, and

provide much higher security assurance than software‐based solutions.

Since HSMs are considered a security best practice, they also reduce the

cost of compliance, not only because they centralize key management and


reduce the need for key rotation due to stronger key protection, but also

because they make it easy to demonstrate compliance with security

guidelines to auditors. Finally, HSMs can add international certifications,

such as FIPS 140‐2 and Common Criteria, to an organization’s security

solution. Thales HSMs offer off‐the‐shelf integration for managing keys in

Microsoft SQL Server 2008.

About the authors

Rob Walters

Rob Walters has worked with SQL Server for the past 10 years. He is the

lead author of Accelerated SQL Server 2008 (Apress) and co‐author of

Programming SQL Server 2005 (Microsoft Press) and Pro SQL Server 2005

(Apress), among other books.

Rob holds a BS in Electrical Engineering from Michigan State University

and an MBA from Seattle University.

Over the past decade, Rob has held various positions within Microsoft,

including program manager for database security. He currently resides in

the Boston area.

Christian Kirsch

Chris Kirsch has more than 12 years of experience in enterprise data

protection. He has published several articles on IT security in international

media and has spoken on the topic at several security conferences.

Based in Cambridge, Massachusetts, Chris is currently senior manager,

international product marketing for hardware security modules at Thales.

Previously, he worked with PGP Corporation in Germany and the United

States as a product marketing manager for enterprise security software.

Chris has also held product management positions at several encryption

software vendors. In these roles, he became familiar with the security

concerns and challenges of today’s leading global organizations.


Chris has a Bachelor of Arts in Politics with International Relations from

the University of Warwick, as well as a business degree from the

Akademie fuer Marketing‐Kommunikation in Frankfurt.

Further reading Thales HSMs

http://iss.thalesgroup.com/en/Products/Hardware%20Security%20

Modules.aspx

Thales Database Security Option Pack

http://iss.thalesgroup.com/~/media/Files/Solution%20Sheets/Micros

oft%20SQL%20Server%202008%20Transparent%20Data%20Encrypt

ion.ashx

Thales netHSM installation video

http://iss.thalesgroup.com/en/Products/Hardware%20Security%20

Modules/netHSM.aspx (Features tab)

Thales Integration Guide—Database Security Option Pack for SQL

Server 2008

http://iss.thalesgroup.com/Resources/~/media/Files/Integration%20

Guides/Microsoft_Database_Security_Option_Pack_SQL_Server_20

08_Windows.ashx

“A Focus on Security Yields Compliance for Free,” white paper

http://iss.thalesgroup.com/l/program/Reymann%20White%20Paper.

aspx

“A Focus on Security Yields Compliance for Free,” webinar

http://iss.thalesgroup.com/~/media/Files/Webinars/SecurityYieldsC

ompliance_May2009_Final_Slides.ashx


“SQL Server Encryption” (and subchapters), MSDN Library

http://msdn.microsoft.com/en‐us/library/bb510663.aspx

“Database Encryption in SQL Server 2008 Enterprise Edition,”

MSDN Library

http://msdn.microsoft.com/en‐us/library/cc278098.aspx

Index Advanced Encryption Standard (AES), 10, 20, 42

algorithm, 9 asymmetric encryption, 10 asymmetric key, 44 AUTHORIZATION, 20 backup, 13 BitLocker Drive Encryption, 16 catalog view, 21 cell‐level encryption, 15, 20, 42 certificates, 24 ciphertext, 9 CLOSE KEY, 43 clustering, 34 failover, 35

Common Criteria, 38, 49 CPU, 31 CREATE CRYPTOGRAPHIC PROVIDER, 40

CREATE MASTER KEY, 25 CREATE SYMMETRIC KEY, 20, 42

cryptographic architecture, 34 cryptographic views, 41 database encryption, 7 Database Encryption Key (DEK), 44

Database Security Option Pack, 39

DecryptByKey, 23 Decryption, 9

DES, 42 disaster recovery, 13 DMVs, 41 dynamic management views, 41 EncryptByKey, 21 Encryption, 9 Encryption and Key Management Industry Benchmark Report, 5

EXECUTE AS, 22 Extensible Key Management (EKM), 6, 15, 33, 39 provider, 39

FIPS 140‐2, 38, 49 foreign keys, 31 hardware security modules (HSMs), 10, 33, 34, 48 Thales, 35, 39

high availability, 13 I/O, 31 indexing, 30 Integration Guide: Database Security Option Pack for SQL Server 2008, 19

k of n, 36 key, 9 history, 36 recovery, 36

key archive, 13 key management centralized, 35


key pair, 10, 44 key rotation, 12 key wrapping, 11 Management Studio, 19, 21 Microsoft SQL Server 2005, 7 mirroring, 35 module key, 36 nShield Connect, 39 OPEN KEY, 43 OPEN SYMMETRIC KEY, 22 operational efficiency, 14, 35 Operator Card Set (OCS), 40 password, 20, 24 Payment Card Industry Data Security Standard (PCI DSS), 7

performance, 31 plaintext, 9 Ponemon Institute, 8 power supplies dual, 34

primary keys, 30 private key, 10 provider_id, 41 public‐key encryption, 10 quorum, 36 recovery, 13

referential integrity, 30 re‐keying, 13 relational databases, 30 REVERT, 26 RSA, 42 scalability, 35 security assurance, 37 Security World, 36, 39 separation of duties, 12, 36, 37 smart cards, 36 SQL Server Management Studio, 19, 21

symmetric encryption, 10 sys.cryptographic_providers, 41 sys.dm_cryptographic_provider_properties, 41

Sys.symmetric_keys, 21 TempDB, 32 third‐party database encryption, 14

transparency, 29 Transparent Data Encryption (TDE), 15, 27, 44

Triple_DES, 42 US Cost of Data Breach Study, 8 X.509, 24

Understanding cell- level encryption and Transparent Data Encryption in Microsoft SQL Server 2008, and managing keys with hardware security modules

This technical guide for database administrators and IT

security experts demonstrates how you can protect your

sensitive data with the native database encryption functions

of Microsoft SQL Server 2008, such as cell- level encryption

and Transparent Data Encryption, and manage and protect

encryption keys with hardware security modules (HSMs).

After an introduction to encryption technology, you’l l learn

about these new security features of Microsoft SQL Server

2008. You’l l be able to choose the right approach to pro-

tecting your data and understand Extensible Key Manage-

ment and HSMs. Many practical examples and T-SQL l istings

show the different ways in which you can encrypt your data-

base and centrally manage keys. After completing this book,

you’l l be able to make an informed decision about how to

encrypt your databases and manage and protect your

encryption keys.

Information Security Professionals Series

Date post:	10-Mar-2016
Category:	Documents
Upload:	mudito-ap
View:	248 times
Download:	7 times

SQL Server 2008 integration guide with nShield

Documents