USE masterGO -- create database master key if it doesn't exist CREATE MASTER KEY ENCRYPTION BY PASSWORD = 'sleepyguyjn$&adsg12345' GO --create TDE certificate from backup CREATE CERTIFIC
Trang 1Restoring Encrypted Backups
to Another Server or Instance
If you attempt to restore an encrypted backup to a server that doesn’t have the correct server certificate, you’ll get the following error:
Msg 33111, Level 16, State 3, Line 1
Cannot find server certificate with thumbprint
'0xCA741797B81ED8D1305EAFF5A747BA51E1DAB80D'.
Msg 3013, Level 16, State 1, Line 1
RESTORE DATABASE is terminating abnormally
On the new server you need to create the server certificate from the backup
of the server certificate from the server where the database originated from The syntax for restoring is as follows:
Configuring & Implementing…
Effect on Backups
Once a SQL database is encrypted via TDE, all the backups are also encrypted That’s the easy part.
Backups and secure storage of the SMK, certificates, and DMKs are critical
If these keys are lost, the backups are not recoverable It is recommended best practice to back up the keys and certificates in SQL Server As part of the database backup process, store the certificate and private key backup files
in a physically safe location but separate from the database backup files Backing up these keys to a secure location is critical; if the keys fall into the wrong hands they could be used to access your data If it’s worth encrypting, it’s important to keep the keys safe The following example illustrates the SQL command to back up the DEK and certificate
BACKUP CERTIFICATE [TESTDB_TDE]
TO FILE = 'SAFE_LOCATION\TESTDB_TDE.2009.01.01.cer'
WITH PRIVATE KEY
(FILE = 'SAFE_LOCATION\ TESTDB_TDE.2009.01.01.pvk',
ENCRYPTION BY PASSWORD = 'TESTDB TD3 P@sswurd')
Trang 2USE master
GO
create database master key if it doesn't exist
CREATE MASTER KEY ENCRYPTION BY PASSWORD = 'sleepyguyjn$&adsg12345'
GO
create TDE certificate from backup
CREATE CERTIFICATE Cert1
FROM FILE = 'c:\Cert''
WITH PRIVATE KEY (FILE = 'c:\MyCertPrivKey',
DECRYPTION BY PASSWORD = 'this#is#a$ecret')
GO
Once the key has been restored, you may restore the database normally, and you
should see no errors
RESTORE DATABASE MarksEncryptedDB
FROM DISK = 'c:\MarksEncryptedDB_11_14_2008.bak'
WITH move 'MarksEncryptedDB' TO 'e:\data\MarksEncryptedDB.mdf',
move 'MarksEncryptedDB_log' TO 'f:\logs\MarksEncryptedDB.ldf',
recovery
GO
Third-Party Encryption Tools
SQL Server 2008 introduced Extensible Key Management (EKM) EKM provides
an interface for third-party vendors to manage and store encryption keys outside of
the database EKM also enables third-party vendors to register their modules in
SQL Server Once registered, SQL Server can use the third party encryption tools
as well as key management functionality
A number of third-party tools are available, such as NetLib’s Encryptionizer
SQL Server encryption These tools are not necessarily on the test, but it’s a good
idea as a DBA to be aware they exist and they do have their place in the encryption scheme
HSM devices provide a central system that is dedicated to performing
symmetric and asymmetric cryptography to one or multiple servers on a
network, thereby providing better performance In essence, it offloads the
encryption and decryption processing as well as provides a remote key
management solution
Important Note: In SQL server 2008, EKM does not support certificates
Trang 3Summary of Exam Objectives
Encryption is a way of keeping data confidential and unreadable by unauthorized users SQL Server 2008 includes several enhancements in the area of encryption, including Transparent Data Encryption (TDE) Without TDE or another post-backup encryption method, backup data and log files can be restored on another server and information can be stolen
Keys are the basis of cryptography, and SQL Server 2008 uses symmetric and asymmetric keys for encryption Symmetric keys use the same password to encrypt and decrypt data while asymmetric keys use one password (public key) to encrypt the data and another (private key) to decrypt the data
Cell-level encryption, a form of encryption that was introduced in SQL Server 2005, provides developers with a granular level of encryption for their applications that have specific data security requirements Encrypting File System (EFS) provides file and folder-level encryption using the Windows Generally, EFS
is used to protect user data on a single computer used by a single user
Extensible Key Management (EKM) is a feature introduced in SQL Server 2008 EKM provides an interface for third-party vendors to manage and store encryption keys outside of the database as well as provide the ability to register their modules in SQL Server In SQL Server 2008, EKM does not support certificates Once registered, SQL Server can use the third party encryption tools as well as key management functionality
After reading this chapter, you should have an understanding of why and when you should use the various types of encryption that SQL Server 2008 offers
Exam Objectives Fast Track
Understanding Transparent Data Encryption
SQL Server 2008 introduced transparent data encryption (TDE) to provide
˛
the ability to encrypt entire databases, data, and log files without the requirement of application changes and with minimal performance impact Without TDE or another post-backup encryption method, the backup data
˛
and log files can be restored on another server and information can be stolen
At its core TDE uses the Windows Data Protection application program
˛
interface (API) to encrypt and decrypt keys and data
Trang 4Encryption Keys
Two types of keys are used in SQL Server for encryption, symmetric and
˛
asymmetric
Symmetric keys use the same password to encrypt and decrypt data,
˛
whereas asymmetric keys use one password (public key) to encrypt the
data and another (private key) to decrypt the data
External key management (EKM), new in SQL Server 2008, provides
˛
organizations with hardware-based security modules (HSM) or external
software based-security modules to interface with SQL server to
externally manage the encryption keys as well as enable encryption
and decryption
Cell- and Column-Level Encryption
Introduced in SQL Server 2005, cell-level encryption provides developers
˛
with a granular level of encryption for their applications that have specific
data security requirements
Cell- and column-level encryption require that the column to be
˛
encrypted in the table schema be stored as a varbinary object.
The main difference between cell- and column-level encryption is that
˛
the expense of column-level encryption is magnified by the number of
rows in the table
EFS Encryption (Through the OS)
Windows 2000 introduced Encrypting File System (EFS), which
˛
provides file- and folder-level encryption using the Windows operating
system
One of the disadvantages of using EFS is that SQL Server will experience
˛
decreased performance Since EFS does not support asynchronous input/
output (I/O), I/O will be serialized and become the bottleneck
Although it is possible to implement EFS on SQL Server databases,
˛
the concurrency requirement makes EFS an unattractive option for
encryption
Trang 5Third-Party Encryption Tools
SQL Server 2008 introduced Extensible Key Management (EKM)
˛
EKM provides an interface for third-party vendors to manage and store
˛
encryption keys outside of the database EKM also enables third-party vendors to register their modules in SQL Server
A number of third-party tools are available, such as NetLib’s Encryptionizer
˛
SQL Server encryption