Keeping your data secure with SQL Server 2016 Technical White Paper Published: August 2016 Applies to: Microsoft SQL Server 2016 and SQL Server 2014 Summary: This white paper examines data security features, including new and existing SQL Server security features, Windows Server features, and recommended practices, organized by protection layer (client, network, database, and host) and by feature/practice type (access control, data encryption, and proactive monitoring). Copyright The information contained in this document represents the current view of Microsoft Corporation on the issues discussed as of the date of publication. Because Microsoft must respond to changing market conditions, it should not be interpreted to be a commitment on the part of Microsoft, and Microsoft cannot guarantee the accuracy of any information presented after the date of publication. This white paper is for informational purposes only. MICROSOFT MAKES NO WARRANTIES, EXPRESS, IMPLIED, OR STATUTORY, AS TO THE INFORMATION IN THIS DOCUMENT. Complying with all applicable copyright laws is the responsibility of the user. Without limiting the rights under copyright, no part of this document may be reproduced, stored in, or introduced into a retrieval system, or transmitted in any form or by any means (electronic, mechanical, photocopying, recording, or otherwise), or for any purpose, without the express written permission of Microsoft Corporation. Microsoft may have patents, patent applications, trademarks, copyrights, or other intellectual property rights covering subject matter in this document. Except as expressly provided in any written license agreement from Microsoft, the furnishing of this document does not give you any license to these patents, trademarks, copyrights, or other intellectual property. © 2016 Microsoft Corporation. All rights reserved. Microsoft, Active Directory, Microsoft Azure, Excel, SharePoint, SQL Server, Windows, and Windows Server, are trademarks of the Microsoft group of companies. All other trademarks are property of their respective owners. Page 2 Contents Introduction ........................................................................................................................................4 Security feature areas overview......................................................................................................4 Protection layers overview .............................................................................................................. 5 Data application protection..................................................................................................................................5 Data network protection .......................................................................................................................................7 Database protection ..............................................................................................................................................8 Database host protection .................................................................................................................................... 10 Conclusion ..........................................................................................................................................11 Appendix: Security features in detail .......................................................................................... 12 More information ............................................................................................................................ 18 Feedback ............................................................................................................................................ 18 Page 3 Introduction Microsoft SQL Server has been rated as the most secure database management system (DBMS) for several years. According to the National Institute of Standards and Technology (NIST) public security board, SQL Server has the lowest number of security vulnerabilities across major database vendors. In addition, the Information Technology Industry Council (ITIC)1 has deemed SQL Server “the most secure database.” SQL Server is designed to be secure by reducing potential security risks by default, allowing administrators to selectively choose connectivity and remote features based on their organization’s needs. Security needs are constantly changing, as the landscape of data, volume, accessibility, and potential threats evolves. The latest features in SQL Server 2016 significantly raise the bar for data security, providing new and enhanced features to protect data from various threats. Understanding security features and best practices can be challenging, even for developers and administrators familiar with previous versions of SQL Server. This paper provides insight on how to frame layers of data protection, the focus areas for security features, and potential scenarios in which features can be applied to limit exposure to security threats. Security feature areas overview SQL Server 2016 security features can be organized into three areas of focus. Each focus area represents a data security concept: an approach to securing data from potential breaches or threats. These areas include access control, in which permissions are strictly defined for users and applications to prevent breaches; data encryption, designed to prevent use of sensitive data by unauthorized parties; and proactive monitoring, which focuses on tracking logon attempts and potentially malicious activity. 1 Information Technology Intelligence Corp. (ITIC), SQL Server Delivers Industry-Leading Security, September 2012. Page 4 In addition to new and updated SQL Server security features available in SQL Server 2016, we’ll review a few security practices associated with database security, such as Active Directory authentication, Windows Firewall, and hard drive encryption. The intent is to provide insight into capabilities available to developers and database administrators for securing data. Protection layers overview In an effort to organize security features by effective scope, we break down the overall concept of data security into several layers. Each layer represents a logical partition of the security landscape by type of access, accessible content, and security concerns. Security features and practices are grouped into the protection layers to which they apply. Some of these are applicable to more than one layer. In this paper, we will briefly examine each layer outlined above, and review a scenario to illustrate how specific security features and practices can be employed to secure sensitive data. Data application protection Data application protection generally focuses on permission: enabling data access for authorized users, and disabling access for others. It’s also an area that, from a DBA perspective, is often difficult to control as it’s up to developers to provide secure functionality within an application. Traditionally, the logic of obfuscating sensitive data has been developed in the application layer. This requires security to be implemented across all modules and applications accessing the data. Alternatively, special views must be created to avoid exposure of sensitive data. These views can impact database performance and are susceptible to errors. SQL Server 2016 provides features that limit access to data fields containing Page 5 sensitive information and includes an additional layer of application security to keep valuable personal data protected even when the data is in-motion. Consider a scenario where a hospital has stringent requirements to control access to patient data at a more granular level than what simply granting, revoking, or denying permissions provides. For example, a database application that provides access to patient data may require individual doctors to be restricted to accessing information related to only their patients. Similar requirements exist in many environments, including finance, law, government, and military applications. Row-Level Security (RLS) is a SQL Server feature that simplifies and centralizes access logic in a security policy at a per-row level. RLS enables customers to control access to rows in a database table based on the characteristics of the user executing a T-SQL statement (such as group membership or execution context). RLS uses filter and block predicates to determine which records are visible for a particular transaction, protecting data from unauthorized reads or writes (update/delete). Since predicates are evaluated at the Database Engine, no additional logic is required in the client application. In this same hospital scenario, consider another example where customer representatives need to address patient questions. When a patient record comes up, the representative needs the ability to see certain information to respond accurately. Some information, such as specific private health details or financial or insurance information, needs to remain confidential for HIPAA compliance. SQL Server 2016 introduces a new feature called Dynamic Data Masking (DDM). With DDM, IT administrators can take simple steps to define policies, or rules, to mask any personally identifiable information that is not needed for the customer interaction. The ability to view “unmasked” data is limited to those with the correct authorization, managed by security group membership. This way, the service representative can view a patient record without having access to confidential information. Patient information is secured,