ManagingDataEncryption•Chapter5 177 based-security modules to interface with SQL server to externally manage the encryption keys as well as enable encryption and decryption. Te s T Da y Ti p 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. 178 Chapter5•ManagingDataEncryption 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. 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 ManagingDataEncryption•Chapter5 179 First 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 CONVERT or CAST are needed to format the 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. 180 Chapter5•ManagingDataEncryption These 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 ManagingDataEncryption•Chapter5 181 when 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. . 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,. 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. 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