ptg 334 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. Download from www.wowebook.com ptg CHAPTER 12 Data Encryption IN THIS CHAPTER . What’s New in Data Encryption . An Overview of Data Security . An Overview of Data Encryption . SQL Server Key Management . Column-Level Encryption . Transpar ent Data Enc r yption . Column-Level Encryption Versus Transparent Data Encr yption 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 addition 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. Download from www.wowebook.com ptg 336 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 security 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. Download from www.wowebook.com ptg 337 An Overview of Data Security 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 addition, 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. 12 Download from www.wowebook.com ptg 338 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, 128-bit RC4, DESX, 128- bit AES, 192-bit AES, and 256-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: Download from www.wowebook.com ptg 339 SQL Server Key Management . 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 asymmetric keys and digital certificates. As an administrator, you probably need to manage at least the upper level of keys in the hierarchy shown in Figure 12.1. Each key 12 Download from www.wowebook.com ptg 340 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 Protection 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 to features of the operating system or third-party products. Download from www.wowebook.com ptg 341 SQL Server Key Management 12 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. Download from www.wowebook.com ptg 342 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 Download from www.wowebook.com ptg 343 Column-Level Encryption 12 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 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. Download from www.wowebook.com . 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. 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. 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