based-security modules to interface with SQL server to externally manage the encryption keys as well as enable encryption and decryption.. Database Encryption Keys Note that there are a
Trang 1based-security modules to interface with SQL server to externally manage the
encryption keys as well as enable encryption and decryption
TesT Day Tip
Understand that TDE is not a form of access control If someone has
permission to access the database, TDE will not prevent them from
accessing the data Note that they do not need permission to the DEK
or a password.
Database Encryption Keys
Note that there are a number of encryption algorithms you may choose when you
create the DEK Not all operating systems support all types of encryptions, so be
sure you select an encryption scheme that is supported by the operating system
you’ll be using
The algorithms supported by SQL Server are: WITH ALGORITHM =
{AES_128 | AES_192 | AES_256 | TRIPLE_DES_3KEY}
Best Practices for
Managing Database Keys
Managing SQL Server keys consists of creating, deleting, and modifying database
keys, as well as backing up and restoring database keys
To manage symmetric keys, you can use the tools included in SQL Server to do
the following:
Back up a copy of the server and database keys so that you can use them
■
■
in the event a server needs to be reinstalled, or for a planned migration
Restore a previously saved key to a database to a new server instance
■
■
This enables a new server instance to access existing data that it did not
originally encrypt
Re-create keys and re-encrypt data in the unlikely event that the key
■
■
is compromised As a security best practice, you should re-create
the keys periodically to protect the server from attacks that try to
decipher the keys
Trang 2Cell- 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 While this provides the application development much flexibility,
it has additional performance and space costs
First of all, cell- and column-level encryption require that the column to be
encrypted in the table schema be stored as a varbinary object This requires additional
processing and disk space overhead Specifically, most data is usually a character or numeric field So there is an additional performance cost of converting the data to
and from a varbinary type in addition to the processing required to encrypt and
decrypt each cell in a table
Column-level encryption is established in the same manner as cell-level
encryption 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
Let’s look at an example of encrypting social security numbers in an Employees table (see Figure 5.1) For demonstration purposes, we have a plaintext (Customer_SSN) and an encrypted column (Customer_SSN_asym) to contain social security
information
Figure 5.1 A List of Employees
Trang 3First let’s create the asymmetric key to use for encrypting the customer_SSN_asym
column For simplicity we have created a simple asymmetric key with password that
is used for decryption
CREATE ASYMMETRIC KEY dboAsymKey AUTHORIZATION dbo
WITH ALGORITHM = RSA_2048
ENCRYPTION BY PASSWORD =N'SylviaP@zzwurd';
Now let’s load a couple of records
DECLARE @ssn1 VARCHAR(100) = '111-11-1111'
DECLARE @ssn2 VARCHAR(100) = '222-22-2222'
INSERT into Customers (Customer_first_name, Customer_last_name, Customer_SSN,
Customer_SSN_asym, customer_city, customer_zip)
VALUES
('Jane', 'Smith' , @ssn1, EncryptByAsymKey(AsymKey_ID('dboAsymKey'),@ssn1),
'Redmond', 98052),
('John', 'Doe', @ssn2, EncryptByAsymKey(AsymKey_ID('dboAsymKey'),@ssn2),
'Redmond', 98054);
Now let’s decrypt the column Customer_SSN_asym to ensure that it is the same
as the column Customer_SSN (see Figure 5.2).
Figure 5.2 Decrypting Employees’ Social Security Numbers
This example illustrates the breakdown of an encryption chain in that a key
requires input of a password The key problems here include the following:
How and where to store the password for decrypting asymmetric keys
■
■
The built-in functions
■
data properly
Although not applicable to the social security numbers, per se, column
■
■
encryption does not allow for the field to be used as an index and can not
be used in a search (WHERE) clause
Trang 4These issues can be solved with an investment of software architecture design and programming resources
Head of the Class…
Pros and Cons of Data Encryption
Which form of encryption is the best for my situation?
Well the answer is, it depends!
Data encryption provides a great security benefit, but it also has per-formance, disk, and administrative costs.
Asymmetric key encryption algorithms are more compute intensive than symmetric key algorithms In general, it is more efficient to encrypt large datasets using a symmetric key, while encrypting the symmetric key with an asymmetric key.
Although TDE encryption overhead is low, there is a small overhead cost in the operational performance and additional disk space for the encrypted database Most of the encryption impact is at the time of encrypting the database.
TDE encryption over cell- or column-level encryption yields various benefits First, no additional application code or application code changes are required for encryption.
The major benefit with TDE is that the database data at rest—specifically any copies of the database’s data, log, and backup files—cannot be accessed without the proper security permissions via the TDE keys in the database Backups cannot be recovered to a different SQL Server 2008 instance without the proper encryption keys and certificates in the master database of a different SQL Server instance.
EFS Encryption
(Through the Operating System)
Windows 2000 introduced Encrypting File System (EFS), which provides file- and folder-level encryption using the Windows operating system Generally, EFS is used
to protect user data on a single computer used by a single user Both EFS and TDE
protect data at rest Data at rest refers to data on a disk The security issues arise
Trang 5when files containing personal (or organizational) identifiable information are
susceptible to access to nonauthorized users
Currently TDE does not support encryption of the system databases (master,
model, msdb, and resource) However, in some scenarios EFS can be used to
encrypt the system databases 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
Synchronous I/O is a key database management system requirement to support
high-concurrent transactions on enterprise database and applications
In most cases, EFS is not a good idea; certainly with SQL Server 2008, TDE
will be a better choice
Another issue to using EFS on database files is in the area of administration
Although key management is simpler with the use of the Windows certificate store
and offers a data recovery path if keys are lost, database administration would require file administration privileges on the operating system level Most organizations do
not provide this operating system privilege to a database administrator
Head of the Class…
Concurrency and the Use of EFS
Although it is possible to implement EFS on SQL Server databases, the
concurrency requirement makes EFS an unattractive option for encryption
The whole point of using SQL Server over a flat file or an Excel file is
concurrency The primary job of a database is to ensure that database
transactions are processed concurrently while maintaining data integrity
The cost of application and database bottleneck and performance
degradation would be greater than the savings and safety of using EFS.
EFS in a Clustered Environment
Special care must be taken to use file encryption in a clustered environment All
cluster computer accounts and the virtual computer account must be trusted for
delegation The cluster needs to be configured to support Kerberos authentication
The files need to be encrypted on the cluster’s drive