ptg 354 FIGURE 12.4 Viewing TDE properties in SSMS. FIGURE 12.3 Modifying TDE properties in SSMS. Backing up the certificate, private key, and master key for the server is relatively straightfor- ward. An example of backing up the master key is shown in the following SQL statement: BACKUP MASTER KEY TO FILE = ‘c:\mssql2008\backup\masterkey’ ENCRYPTION BY PASSWORD = ‘somekeybackuppassword$$’ CHAPTER 12 Data Encryption Download from www.wowebook.com ptg 355 Transparent Data Encr yption 12 Backing up the certificate and associated private key also uses the BACKUP command. The following example backs up the certificate created in Listing 12.1: BACKUP CERTIFICATE MyCertificate TO FILE = ‘c:\mssql2008\backup\MyCertificate’ WITH PRIVATE KEY ( FILE = ‘c:\mssql2008\backup\MyCertificatePrivateKey’ , ENCRYPTION BY PASSWORD = ‘somecertbackuppassword$$’ ) If you want to restore a database backup on another server instance, a master key for the server must exist. If one does not exist, you can create one by using the CREATE MASTER KEY ENCRYPTION syntax. After creating the master key, you are able to create the TDE certificate from a backup of the certificate from the original SQL Server instance, as shown in the following example: CREATE CERTIFICATE MyCertificate FROM FILE = ‘c:\mssql2008\backup\MyCertificate’ WITH PRIVATE KEY (FILE = ‘c:\mssql2008\backup\MyCertificatePrivateKey’, DECRYPTION BY PASSWORD = ‘somecertbackuppassword$$’) After the certificate is restored on the other server instance, you can restore the encrypted database backup. At this point, the restore can be performed just as you would restore any unencrypted database backup. The restored database is also encrypted and behaves like the original TDE database. TDE is a relatively simple and effective way to encrypt and protect your data. Other encryption methods that exist with SQL Server can protect different elements of your database. Encryption can be applied to columns of data, an entire table, as well as the communication that occurs between databases and the clients that access them. The level of encryption and need to use it depend on the type of data you are securing. Limitations of TDE Although TDE offers many benefits over column-level encryption, it has some of its own limitations, which are important to consider. They include . TDE is not granular like column-level encryption. The entire database is encrypted, but only on disk. Sensitive data such as Social Security numbers or credit card numbers can be seen by anyone who has permission to access those columns. TDE also does not prevent DBAs from viewing any data in the database. . TDE does not protect communications between client applications and SQL Server. Network encryption methods should be used to protect sensitive data flowing over the network. . FILESTREAM data is not encrypted. . When any one database on a SQL Server instance has TDE enabled, the tempdb data- base is also automatically encrypted. This can affect performance for both encrypted and nonencrypted databases running on the same instance. Download from www.wowebook.com ptg 356 CHAPTER 12 Data Encryption TABLE 12.1 Comparison of Column-Level Encryption and Transparent Data Encryption Features/Limitations Column-Level Encryption Transparent Data Encryption Data is encrypted on disk and backups Yes Yes Supports HSMs Yes Yes Data level of encryp- tion Granular, at the column level Encrypts the entire database only User level of encryp- tion Encrypted data can be restricted at the user level on a need-to-know basis Any user with sufficient database permissions can view encrypted data Impact on applica- tions Database applications need to be modified Completely transparent to applica- tions and end users Indexing of encrypted data Encrypted columns cannot be indexed No restrictions on indexes Performance impact May be significant depending on the type of encryption key used Small impact on performance (3–5%) . Databases encrypted with TDE can’t take advantage of SQL Server 2008’s new backup compression. If you want to take advantage of both backup compression and encryption, you have to use a third-party application, such as Idera's SQL Safe Backup or Redgate's SQL Backup, which both have the capability to both compress and encrypt backups. Column-Level Encryption Versus Transparent Data Encryption So is column-level encryption or transparent data encryption the right solution for your systems? Both column-level encryption and transparent data encryption provide a means of obfuscating sensitive data to protect it from unauthorized access. However, they do so in different ways. TDE prevents the unauthorized access of the contents of the database files and backups, but does not protect sensitive data within the database from being viewed by authorized users or database administrators. Column-level encryption provides more granular control over the data being encrypted but is not transparent to your applications. Table 12.1 lists the similarities and differences between column-level encryption and TDE. For some organizations, you might want to consider implementing both column-level encryption along with TDE for a database. Although this combination is more complex to set up and administer, it offers greater security and encryption granularity than does either method used alone. TDE protects the database files and backups from unauthorized Download from www.wowebook.com ptg 357 Summary 12 access, whereas column-level encryption protects sensitive data within the database from being accessed by authorized users, including DBAs. Implementing TDE in conjunction with cell-level encryption provides a layered approach to data security, which enhances its effectiveness. The main disadvantage to implementing column-level encryption is that it isn’t transpar- ent to the end-user applications. In addition to requiring changes to the database schema, it also requires changes in the applications to include the proper function calls to encrypt and decrypt the data as it is stored and retrieved. Another issue with column-level encryp- tion is that you cannot index encrypted columns, nor can you generate statistics on the encrypted columns. This can affect query performance because search arguments that reference encrypted columns cannot be optimized. For this reason, typically only the most sensitive columns of a table that do not need to be indexed are encrypted. Summary Chapter 11, “Security and User Administration,” discusses methods to secure and control the access to your SQL Server data via login and user security to prevent unauthorized users from accessing your SQL Server instances and databases. Column-level encryption, as discussed here, takes these protections a step further by preventing authorized users, such as your database or server administrators, from viewing sensitive data within a database. Transparent data encryption protects all your data from being accessed by unauthorized users in the event that your database files or backups are lost or stolen. Chapter 13, “Security and Compliance,” discusses security methods available in SQL Server and how they can be implemented to meet your security compliance requirements. It also covers the new data auditing methods you can use to track changes to your data and database objects. Download from www.wowebook.com ptg This page intentionally left blank Download from www.wowebook.com ptg CHAPTER 13 Security and Compliance IN THIS CHAPTER . Exposure and Risk . Across the Life Cycle . The Security Big Picture . Identity Access Management Components . Compliance and SQL Server . SQL Server Auditing . Setting Up Auditing via T-SQL . SQL Injection Is Easy to Do As you complete what you think is your best database design and application on the planet, you stop yourself dead in your tracks and say, with hesitation, “What about the security and compliance implications?” Now is not the time to start thinking about these aspects. In fact, as we show you in this chapter, you should start considering these issues from the beginning of the development life cycle. With the growth of software and database development in the world, there is a rise in the demand for security best practices to achieve the goals of creating secure software. Best practices must start from the glass and reach through the application, to the database layer, and even to the oper- ating system and the physical file levels. Best practices are also meant to be scrutinized for overall results on the basis of the level of security, efficiency, and complexity they provide. How much and which best practice to use can also be considered on the basis of confidentiality, integrity, and availability (which is known as CIA). Software security must be considered at many layers and is additive in nature— each layer providing the necessary security and compliance of one part of the bigger puzzle. To get it right, you must “design in” security from the beginning. In this chapter we discuss security aspects in conjunction with a traditional development life cycle; this includes aspects such as vulnerability assessments, threat modeling, and identity management. You can take many steps to prevent SQL injection, for example, and other vulnerabilities. We also talk about compliance aspects in regards to global and regional regulations such as the Health Insurance Portability and Accountability Act (also known as HIPAA), Download from www.wowebook.com ptg 360 CHAPTER 13 Security and Compliance Limited Exposure (Internal/Intranet Only) Exposable (External Internet) Low Sensitivity (Public) Low Risk Medium Risk Medium Sensitivity (Confidential) Medium Risk High Risk High Sensitivity (Highly Confidential) High Risk High Risk Data/Application Exposure End Points FIGURE 13.1 The exposure endpoints “risk” by category of data/application sensitivity. the Payment Card Industry (PCI) standards, and data privacy regulations such as Personally Identifiable Information (PII). We also provide a simple example of using the SQL Server Auditing feature that can be extremely useful in identifying and monitoring compliance of access and usage at the SQL Server database or object levels. And lastly, we show you how to do some malicious damage with SQL injection. We show you how to do this so that you can learn how to prevent it. But first, let’s try to better understand what exposure and risk are all about. Exposure and Risk You must understand that security is really “risk management” or “risk mitigation.” It can be very difficult to completely secure an application or environment. However, you are able to control or limit damage by following certain practices. Your data and applications have different levels of security requirements depending on the exposure endpoints (an exposure endpoint is defined by who is using the application and data). Figure 13.1 shows a simple matrix of data and application sensitivity versus the exposure endpoints of that application. By definition, the more external facing your application is (such as to the Internet) and the higher the sensitivity of the data involved, the higher risk precautions you have to take. Let’s say you have an internal company SQL Server–based application that has only very low sensitivity data (public-facing data such as benefits data). You freely share this type of data with whoever wants to see it. The types of controls or rigor are likely very small for this type of application—perhaps as simple as an integrated Active Directory with your SQL Server and read-only access for all user roles. On the other side of the spectrum, you may have applications generating financial trans- actions with credit card data that must have zero vulnerabilities, encrypt data across the network, encrypt data at rest within SQL Server, and use the new SQL auditing feature for database-level monitoring of all data accesses. Download from www.wowebook.com ptg 361 Across the Life Cycle 13 A big part of the risk management aspect is understanding what the impact of this risk would be if your system is compromised. It is always best to identify this aspect up front in some type of risk “cost” or “impact.” Many financially strong companies have gone out of business as a result of security breaches they had not anticipated or considered. It is better to plan for such risk from the beginning. Another aspect to consider is staying compliant with data you use in nonproduction envi- ronments. Often, companies needlessly put their entire livelihood at risk by using live data values in nonproduction environments. If PII or other company-sensitive data is available in your nonproduction environments (such as in Development, Test, and Quality Assurance platforms), you are violating laws and regulations around the globe and putting your company and your customers at risk. You can easily employ data subsetting and masking to your nonproduction data. Putting this practice in place is a great idea. Across the Life Cycle We introduce formal development life-cycle concepts in other chapters. In those chapters, such as Chapter 41, “A Performance and Tuning Methodology,” the emphasis is on design- ing in performance from the beginning. A part of good design is how you have complied with laws and regulations, how you have protected the data you access or store, how you have secured your application and data, and how you have verified all this. For these reasons, we provide some details and describe what must be done across the development life cycle to properly address security and compliance. We term this process the “risk miti- gation” of what you build. Figure 13.2 shows a formal waterfall development life cycle with key security and compli- ance items identified at each relevant phase. Getting into the risk mitigation business starts by giving security and compliance the full commitment and recognition they deserve. This step starts with a clear statement of security and compliance objectives as you are sizing up your application in the assessment phase. These objectives often take the form of stating how you will address the rules, laws, data sensitivities, access considerations, and eventual end users (and the countries they reside in). Next, you focus on the clear identification and specification of all security and scope of compliance. You look at the details of exactly where the compliance or security lines need to be, determine how you must fully address them, and clearly identify which must be adhered to for your application. Often, organizations have security information analysts and data privacy groups that contribute to this part of your development efforts. They, in turn, bring others to the table, such as legal, auditing, and even corporate communica- tions folks. As you go into the design phase, you must complete the full analysis and design of every security and compliance element for your application. As part of this analysis and design phase, you should start enumeration test plans that must be completely verified before your application can be delivered to its users. Download from www.wowebook.com ptg 362 Security & Compliance Implementation Deploy Development Life Cycle Phases Construct Design Initiate Risk Mitigation/Compliance Statement of Security & Compliance Objective Security & Compliance Scope Identified Security & Compliance Analysis & Design Security & Compliance Prototyping Security & Compliance Test Plans Security & Compliance Code/Test Security & Compliance Acceptance System Test & Acceptance Code & Test Prototype Identify & Design Assessment FIGURE 13.2 Security and compliance across the development life cycle. In the prototyping phase, you have a chance to start demonstrating how security, access, privacy, and compliance will be addressed. This phase is very important because of all the complications, rules, laws, and issues that are at stake and must be verified. We have not run a development effort without extensive prototyping of as many security and compli- ance tests as are humanly possible. It is this risk that must be fully addressed early and never as an afterthought! As you fully code and test your database and application, you must never skip the secu- rity testing and validation. It is best to put these tests first in your overall test plans. As your application completely takes shape, a complete application scan for vulnerabilities can be performed. Popular tools such as AppScan are essential tools of the trade for performing this task. Finally, as you near deployment, you should make sure all the security and compliance acceptance tests are met. You need to capture these results fully because the successful completion of this part of acceptance testing can be shown in SOX compliance auditing. The Security Big Picture Now, let’s turn to the bigger security and compliance picture that shows many of the layers involved in a broader security enforcement approach. Figure 13.3 shows many of these layers, starting at the top with solid guidelines, policies, and compliance-reporting capabilities. You must start with these components to guarantee that you are aware of what must be done and have a way to show you are doing what the policies outline. Next, you must define and create other aspects of security and compliance, such as security event management, alerting and monitoring, complete threat models, and vulnerability CHAPTER 13 Security and Compliance Download from www.wowebook.com ptg 363 Internet Protocol Network Access Control Disk Encryption (host) Autonomous System File Integrity Checking (MD5, SH1, ) Policy Compliance Distributed Denial of Service (DDoS) Access Control Lists (ACLs)Intrusion Detection/Intrusion Prevention Database Security Auditing Business Continuity/Disaster Recovery Security Event Management Alerts and Monitoring Vulnerability Assessment Threat Modeling Identity Management/SSO Security Standards & Guidelines Security Compliance Reporting FIGURE 13.3 Security enforcement layers and components. The Security Big Picture 13 assessment objectives. These types of components must also reach into and be enforceable across major events such as disaster recovery (to ensure business continuity) and continue to support what you have deployed around identity management and single sign-on. The next inner layer is where your database security is defined, along with any database- level or database instance–level auditing you put into place. It is also this layer where messy things such as SQL injection can occur and Denial of Service often surfaces. Getting some type of intrusion detection and prevention scheme into place is essential. Clear access controls are also essential. Later in this chapter, we describe some basic SQL Server–based auditing at the database level. Chapters 11, “Security and User Administration,” and 12, “Data Security,” also describe much of what you must do around overall security administration and database-level security. Figure 13.3 highlights these two critical areas. Moving further down the layers of security, you find file integrity checking, secure Internet protocols, disk-level encryption, and other security-enhancing items. They all work together to bring you what should be a more secure (and compliant) place to deploy your applications within. With SQL Server 2008 R2, you are essentially out-of-the-box ready to do absolutely nothing. In other words, Microsoft has taken the policy to “allow nothing,” and any access, execution, or other action must be explicitly granted. Believe it or not, this is the right thing to do. This approach ensures that all objects and accesses are explicitly declared and, by definition, are fulfilling security and many compliance regulations. Download from www.wowebook.com . original SQL Server instance, as shown in the following example: CREATE CERTIFICATE MyCertificate FROM FILE = ‘c:mssql2008ackupMyCertificate’ WITH PRIVATE KEY (FILE = ‘c:mssql2008ackupMyCertificatePrivateKey’,. Picture . Identity Access Management Components . Compliance and SQL Server . SQL Server Auditing . Setting Up Auditing via T -SQL . SQL Injection Is Easy to Do As you complete what you think is. place to deploy your applications within. With SQL Server 2008 R2, you are essentially out-of-the-box ready to do absolutely nothing. In other words, Microsoft has taken the policy to “allow nothing,”