service provider reference architecture - database...

Version 2.021-May-23

Prepared by

<Partner> Services

Service Provider Reference Architecture (SPRA)Multi-Tenant SQL Server 2014

Table of Contents

Executive Summary.........................................................................................51 Solution Overview......................................................................................5

1.1 Multi-Tenancy Models................................................................................................61.2 Architecture Design Strategy....................................................................................8

2 Multi-Tenant SQL Server Infrastructure Design........................................102.1 SQL Server Infrastructure........................................................................................10

2.1.1 Additional Hardware Considerations...........................................................112.1.2 Hyper-V Replica Considerations...................................................................11

2.2 SQL Server Virtual Machine Design.........................................................................112.2.1 SQL Virtual Machine CPU Considerations....................................................122.2.2 SQL Virtual Machine Memory Considerations.............................................122.2.3 SQL Virtual Machine Storage Considerations.............................................142.2.4 SQL Virtual Machine Networking Considerations.......................................162.2.5 SQL Virtual Machine Affinity Considerations..............................................172.2.6 Additional SQL Virtual Machine Considerations.........................................17

3 Multi-Tenant SQL Server Security Design................................................173.1.1 Surface Area Reduction................................................................................183.1.2 Policy-Based Management............................................................................203.1.3 Service Account Selection and Management.............................................213.1.4 Patching and Automatic Windows Update..................................................24

3.2 Encryption...............................................................................................................243.2.1 Data and Database Encryption....................................................................243.2.2 SSL Encryption...............................................................................................28

3.3 Access Control.........................................................................................................293.3.1 Administrator Privileges...............................................................................293.3.2 User-Defined Server Roles............................................................................303.3.3 Database Ownership and Trust....................................................................303.3.4 Lockdown of System Stored Procedures.....................................................31

3.4 Authentication.........................................................................................................323.4.1 Authentication Modes and Logins................................................................32

73

3.4.2 Contained Databases and Authentication..................................................343.5 Network Security.....................................................................................................353.6 Auditing...................................................................................................................38

4 Multi-Tenant SQL Server High Availability and Disaster Recovery Design41

4.1 Network Configuration.............................................................................................444.2 Quorum Configuration.............................................................................................454.3 SQL Server System Data and Availability Groups....................................................46

4.3.1 Jobs, Alerts, Email Operators.......................................................................464.3.2 Backups..........................................................................................................46

5 Shared Database Multi-Tenancy Model Design Considerations...............475.1 Resource Governor..................................................................................................47

5.1.1 Resource Pools, Workload Groups, and Classification...............................475.2 Database Storage....................................................................................................48

6 Multi-Tenant SQL Server Service Management and Automation.............496.1 Operations Manager................................................................................................50

6.1.1 SQL Server 2014 Management Pack............................................................506.2 Orchestrator............................................................................................................526.3 Windows Azure Pack................................................................................................54

6.3.1 Service Management Automation................................................................55

74

Executive SummaryMicrosoft SQL Server is an enterprise class relational database management platform and is an integral and indispensable component in most computing environment today with a significant application ecosystem. With the advent of hosted cloud computing and storage, the opportunity to offer a Microsoft SQL Server as an outsourced service is gaining momentum. This reference architecture is focused on providing sample design guidance and configuration considerations for helping service providers to build a multi-tenant Microsoft SQL Server 2014 platform using Microsoft’s virtualization and management platform. This pattern and practice provides a consistent architecture for Microsoft SQL Server 2014. This document was written to make the result a collection of both solution and product level best practices. Furthermore, this provides guidance for deploying Microsoft SQL Server 2014 using Microsoft’s software defined datacenter patterns and practices built on the Windows Server Hyper-V and System Center platform. The primary goal is to familiarize decision-makers and IT professionals of service providers with an example of how to build a multi-tenant Microsoft SQL Server 2014 platform for their organization. The design presented here could be used as is, or could serve as a starting point from which to drive deeper discussions about the business models, service descriptions, technology, and design decisions. This architecture builds on the guidance and configuration considerations of the Service Provider Reference Architecture Multi-Tenant – Foundation which provides the design of a Multi-Tenant infrastructure that includes Microsoft identity solutions as well as Microsoft’s virtualization and management platform.

1 Solution OverviewThis solution takes advantage of the full range of in-product features for Microsoft SQL Server 2014. This example design is hosted on a Windows Server software-defined infrastructure, which aims to significantly reduce costs through the use of commodity storage and high-speed, low latency network connectivity. Multi-Tenant SQL for Service Providers has been specifically designed with service providers in mind to help service providers to deliver database functionality as a service to their customers. Multi-Tenant SQL service support the following necessary capabilities:

Consumer-based provisioning and management of database instances using on-demand, self-service mechanisms;

5

Automated monitoring of and compliance with provider-defined service definitions, attributes and quality of service levels;

Fine-grained metering of database usageIn addition to these required characteristics, Multi-Tenant SQL also supports granular service elasticity, secure multi-tenancy, automated resource management, and integrated capacity planning.

1.1 Multi-Tenancy ModelsMicrosoft SQL Server supports several isolation models, such as dedicated SQL Server running on dedicated machines (physical or virtual), dedicated SQL Server instance, or dedicated SQL Server database depends on what features and level of flexibility service providers like to offer. Multi-Tenant SQL service will focus on virtualized scenarios to leverage the benefits of infrastructure as a service. The following three multi-tenancy models will be covered:

Virtual Machine Level Isolation: Each tenant database instance will be isolated with Virtual Machine for better feature flexibility and scalability. Virtual machine will be the container for controlling the resources allocation and scalability. Microsoft Hyper-V provides quality of service for various resources, such as CPU, Memory, Network and Storage IOPS.

SQL Server Instance Level Isolation: Each tenant database instance will be isolated with a dedicated SQL Server instance. Multiple SQL Server instances will be hosted on a given virtual machine. SQL Server instance will be the container for controlling the resources allocation, and SQL Server feature related configurations, such as SQL Collation, and patch level, etc. Even instance level isolation provides good security level isolation and feature level isolation, but it has limited options to isolate resources allocation, such as CPU allocation at instance level, and it is also limited to scale, running multiple SQL instances per virtual machine. Therefore, this multi-tenant model is not recommended and will not be focused.

Database Level Isolation: Each tenant database instance will be isolated as contained database running on a shared SQL instance. Resource governor will be leveraged for better resource guarantee and containment for workloads at resource pool level. It is possible to assign tenant database to its own resource pool to achieve database level resource containment. Microsoft SQL 2014 resource governor allows limiting CPU, Memory and IOPS at resource pool level.

76

The following table illustrates benefits and constraints of each model:

Multi-Tenant Model

Benefits Constraints

Database • Optimizes the overhead of resources (memory, CPU, disk space, connections, and more) that are required for each individual instance

• Maximizes value of licenses, since no additional license is required for multiple database instances

• Minimizes the labor and cost of database administration—the fewer individual instances, the easier the system is to monitor and manage

• A common security model (although distinct database and database objects within the model can be secured individually)

• A common service patch level

• The maintenance cycle and downtime

• Platform resources (CPU, Memory, Disk I/O, and more). Resource Governor could help to constraint the resources consumption.

Instance • The data must be very carefully secured.

• The database needs to run at a different service patch level than the other databases.

• The application that depends on the database cannot share a maintenance schedule with other databases, either because the database will require the instance to be started and stopped repeatedly or because the application is too critical to be stopped by the requirements of another application.

• Each instance requires additional resources from the server, including CPU, memory, and disk I/O.

• Memory pools and connections cannot be shared between instances. More resources will be required on the server

• Separate instances require their own logins so additional management efforts will be required.

• Distinct instances require distinct monitoring and administration, which increase cost.

77

Virtual Machine • Server maintenance affects only a single database application.

• The application may require direct access to the server through external stored procedures. This can open the door to certain security risks. By placing the server on its own server, the risk can be mitigated.

• The database can have a unique, isolated security model.

• The database can exercise full control of the resources available on the server.

• Each machine will require a Windows Server license, SQL Server license, and other licenses for antivirus software, backup, monitoring, and more.

• Each additional server requires more resources. If it is a physical machine, the hardware must be purchased, space must be allocated in the data center, and power consumption must be considered. In the case of virtual machines, there is additional load on the host hardware which eventually leads to the need of additional virtual machine host servers.

• Additional servers require additional labor to monitor and maintain the servers.

1.2 Architecture Design StrategyThis Reference Architecture is designed to help service providers deliver a multi-tenant SQL Server environment focusing on Virtual Machine and Database multi-tenancy models described above on a common Infrastructure as a Service platform. Multi-Tenant SQL is designed to help meet the need for robust security, 24/7 reliability, and user productivity. Multi-Tenant SQL is designed for reliability, availability, and performance with a targeted Service Level Agreement (SLA) of 99.9% scheduled uptime. A foundational set of design principles has been employed to make sure that the Multi-Tenant SQL deployment is optimized to deliver a robust set of capabilities and functionalities. The following design principles are the basis for the Multi-Tenant SQL:

78

Efficient multi-tenancy: The goal is to minimize the size of the infrastructure footprint required, while meeting application-level query performance goals.

Elastic scalability: Multi-Tenant SQL supports database and workloads of different sizes. Tenant will be able to provision and deprovision necessary resources to support their database and workloads.

High availability and Business continuity: Multi-Tenant SQL is designed to deliver 99.9% scheduled uptime. Redundant network architecture is part of the geographically dispersed design to handle unscheduled service outages. Data centers act as backups for each other: If one fails, the affected users are transferred to another data center with limited interruption of service.

On-Demand and Self-Service Administration: With a management portal, tenants and administrators can perform tasks associated with SQL. For example, tasks such as creating databases, creating database users, resetting passwords, and backup/restore databases, etc.

Although two multi-tenancy models: virtual machine based and database based have different characteristics, but they do share a common set of SQL Server design principals and considerations. This document will describe those common architectural elements for supporting those two different multi-tenancy models, and also provide special considerations focusing on the differences among those two multi-tenancy models.

79

2 Multi-Tenant SQL Server Infrastructure DesignMulti-Tenant SQL Server Infrastructure will follow the common Infrastructure as a Service framework detailed in the Service Provider Reference Architecture Multi-Tenant – Foundation document. This multi-tenant SQL Server reference architecture will only focus on virtualized SQL Server workload residing on the common Infrastructure provided by the Infrastructure as a Service (IaaS) platform. The following diagram illustrates a typical physical design of such an Infrastructure.

2.1 SQL Server Infrastructure

710

This section looks at the considerations for hosting of SQL Server on virtual machines that are providing Infrastructure as a Service (IaaS).

2.1.1Additional Hardware ConsiderationsIn addition to the common Infrastructure as a Service framework described in the previously referenced document, service providers should also consider use processors that support Second Level Address Translation (SLAT) technologies (that is, SLAT-based processors). SLAT technologies add a second level of paging functionality under the paging tables of x86/x64 processors. They provide an indirection layer that maps virtual machine memory addresses to physical memory addresses, which reduces load on the hypervisor for address translation.SLAT technologies also help to reduce CPU and memory overhead, thereby allowing more virtual machines to be run concurrently on a single Hyper-V machine. The Intel SLAT technology is known as Extended Page Tables (EPT); the AMD SLAT technology is known as Rapid Virtualization Indexing (RVI), formerly Nested Paging Tables (NPT).For optimal performance of demanding workloads like SQL Server, run Windows Server 2012 R2 Hyper-V on SLAT-capable processors/hardware. This offers the additional benefits of improved performance, more virtual machine density per host machine, and reduced overhead.

2.1.2Hyper-V Replica ConsiderationsFor maintaining high availability of mission-critical applications, organizations can replicate their applications on different server workloads in different locations. Hyper-V with Windows Server 2012 R2 provides Hyper-V Replica for replicating virtual machines from one location to another location.Key SQL Server considerations on Hyper-V Replica include:

SQL Server on Hyper-V Replica is supported as long as the flag for EnableWriteOrderPreservationAcrossDisks is set.

If multiple SQL Server virtual machines are tightly coupled with one another, individual virtual machines can fail over to the disaster recovery site, but SQL Server high availability features need to be removed and reconfigured. For this reason, the following SQL Server features are not supported on Hyper-V Replica: availability groups, database mirroring, failover cluster instances, log shipping, and replication.

2.2 SQL Server Virtual Machine DesignIn addition to configuring and establishing the host server as a virtualization server with Hyper-V, it is important to design detailed architecture and system specifications for building virtual machines for expected workloads. It is also necessary to plan for needed resources for the virtual machines. The number of

711

virtual machines you can run on any individual server depends on the server’s hardware configuration and the anticipated workloads.

2.2.1SQL Virtual Machine CPU ConsiderationsIn Windows Server 2012 R2, NUMA is now extended to the virtual environment (virtual NUMA) by making virtual NUMA topology available to the guest operating systems. High-performance applications such as SQL Server support NUMA and use the computer’s NUMA topology to increase performance by considering NUMA when scheduling threads or allocating memory. Therefore, reflecting the underlying NUMA topology into virtual machines running SQL Server 2014 reduces the need for remote memory access, which is critical to improving SQL Server 2014 performance.Identify and categorize virtual machines based on the intensity of the loads they bear (high-intensity loads and low-intensity loads). Then set weights and reserves on the virtual processors accordingly. In this way, you can ensure that a large amount of the CPU cycle is available for virtual machines/virtual processors having high-intensity loads. Whenever possible, avoid the use of emulated devices for SQL Server deployments as this can lead to significant CPU overhead. Install the latest virtual machine Integration Services in each supported guest virtual machine. Virtual machine Integration Services helps to improve I/O throughput and decrease overall CPU usage of guests. This is because it includes enlightened drivers for Hyper-V-specific I/O devices that reduce CPU overhead for I/O.

2.2.2SQL Virtual Machine Memory ConsiderationsFor memory in a virtualized environment, better performance and enhanced support are essential considerations. You must be able to both quickly allocate memory to virtual machines depending on their requirements (peak and off-peak loads) and ensure that the memory is not wasted.Allocate a reasonable amount of memory to the virtual machines running SQL Server workloads so that they can handle the expected loads (at peak and off-peak times). If the memory is not sufficient, it can increase response time or I/O usage for highly intensive workloads. Allocate at least 512 MB of memory for the virtual machine running Windows Server 2012 R2.

Be sure to check the minimum memory requirement of the SQL Server workload that will be hosted on a Windows Server 2012 R2 guest machine and, based on that, allocate the total minimum memory (which is likely to be much higher than 512

712

MB). Dynamic Memory can be enabled to manage the memory requirements dynamically.

There is a limit to the amount of physical memory with which a physical server can be equipped. Therefore, prioritize memory usage based on the requirements of the running virtual machines or the importance of SQL Server workloads, such as OLTP, DW, and BI. Assign memory weights to high-priority virtual machines/workloads so that in the event of a physical memory crunch, memory is first allocated to the higher priority virtual machines.

In general, it is better to leave max server memory at its default setting if using dynamic memory. This allows SQL Server to manage memory dynamically.

To provide better stability to a virtual machine workload, grant Lock Pages in Memory user rights to the SQL Server service account. This helps when Hyper-V Dynamic Memory is trying to reduce the virtual machine’s memory. In such cases, it prevents Windows from paging out a large amount of buffer pool memory from the process, thereby providing a positive performance impact.

If memory pre-allocation is used with SQL Server, it is better to assign only the amount of memory that is required so sufficient memory remains for other processes (thereby avoiding paging). This also ensures that enough memory is available for Analysis Services. (Use the peak value for the Process: Private Bytes counter for the msmdsrv instance to establish this value).

Do not set the memory pre-allocation value too high. Otherwise, other processes may not get sufficient memory at the time when they require it, and this can result in memory paging. If the SQL Server relational engine and Analysis Services are running on the same server, also limit the maximum memory that can be used by the SQL Server relational engine. It is generally sufficient to leave 6-8 GB of memory for the operating system if no other services are running on the same server. However, this can vary depending on workload requirements. When setting the maximum memory for SQL server, consider using the following formula:

Total_Mem - (1% of mem x #_of_NUMA_node) – ( 3% of mem ) – ( 1GB )

By default, a virtual machine gets its preferred NUMA node every time it runs. In due course, an imbalance in the assignment of NUMA nodes to the virtual machines may occur. This may happen because of the ad hoc memory requirements of each

713

virtual machine and because the virtual machines can be started in any order. Therefore, we recommend that you use Perfmon to check the NUMA node preference settings for each running virtual machine. This can be checked through the \Hyper-V VM Vid Partition (*)\ NumaNodeIndex counter. To automatically change NUMA node assignments depending on the requirements of running virtual machines, implement NUMA node balancing. Crossing the NUMA boundary can reduce virtual performance by as much as 8 percent. Therefore, configure a virtual machine to use resources from a single NUMA node. Reduce the max server memory prior to live migration. Use sp_configure or the Memory Weight option in Hyper-V Dynamic Memory to do so. Note that you can use sp_configure only if you have appropriate rights on SQL Server 2014. Adjusting max server memory prior to migration provides following benefits:

Highest success rate for migrations. Most predictable impact to SQL Server workload. Most even rebalancing of physical memory assigned to the virtual machines.

2.2.3SQL Virtual Machine Storage Considerations2.2.3.1Virtual DiskHyper-V in Windows Server 2012 introduces VHDX, a updated version of the VHD format that is designed to handle current and future workloads. VHDX has a much larger storage capacity than the older VHD format. It also provides help protect from data corruption during power failures and optimizes structural alignments to prevent performance degradation on updated, large-sector physical disks. The VHDX format provides the following advanced capabilities that accommodate large workloads like databases:

VHD storage capacity: Supports up to 64 TB. Provides additional data help protect against power failures by logging

updates to the VHDX metadata structures. Enables improved alignment of the VHD format to work well on large sector

physical disks for storing databases. Stores custom metadata about the file to record operating system version or

updates. Provides larger block sizes for dynamic and differencing disks to address the

needs of the SQL Server databases. 4 KB logical sector virtual disk: Allows for increased performance when used

by SQL Server applications designed for 4 KB sectors. Allows physical storage devices to reclaim unused space by trimming into

smaller file sizes. (Trim requires physical disks directly attached to a virtual machine or SCSI disks, as well as trim-compatible hardware.)

Consider using fixed VHDX for hosting SQL database files.

714

2.2.3.2Virtual IDE vs. Virtual SCSIVirtual machines can be configured to use virtual IDE device controllers or virtual SCSI device controllers to connect virtual storage. When starting a virtual machine, the virtual IDE controller is used because the virtual SCSI disks require the operating system to be enlightened during boot-up. IDE is limited to 3 connected disks. (One port is retained for the DVD drive, which is required for updating the integration components.) Virtual SCSI, on the other hand, can have 64 connected disks per controller and 4 controllers per virtual machine, giving a total of 256 virtual SCSI disks per virtual machine. Virtual SCSI also supports hot-add/removal of disks, whereas virtual IDE disks do not.Attach the SQL drives (or any secondary drive) to the Virtual SCSI controller for more flexibility.

2.2.3.3Disk Partition AlignmentAs part of best practices for SQL Server, the disk partition alignment should always be validated when the updated disk is created. SQL Server's physical I/O operations are reads and writes in units of either 64K extents or 8K pages. Those I/O requests make their way through the various I/O subsystems and have to be translated into physical operations against the drives or sets of drives. The number of actual physical I/O operations that it takes to complete SQL Server's request can vary depending on how the disk is prepared.For best practices of SQL Server Disk Partition Alignment, please refer to this document:Disk Partition Alignment Best Practices for SQL Server

2.2.3.4SQL Server Data PartitionAs part of best practices for SQL Server, consider creating multiple virtual disks for placing tempdb, log files, data files and backup files on separate disks. In addition, Windows 2012 R2 introduced storage QoS at virtual disk level to throttle the IOPS, which provides an additional option to balance and control the storage IO consumptions.

2.2.4SQL Virtual Machine Networking ConsiderationsThis subsection discusses four key networking considerations for SQL Server: Dynamic Virtual Machine Queue, Single Root I/O Virtualization, and QoS Bandwidth Management.

715

http://technet.microsoft.com/en-us/library/dd758814.aspx

2.2.4.1Dynamic Virtual Machine Queue Virtual Machine Queue (VMQ) is a feature introduced in Windows Server 2008 R2 that has the Hyper-V server role installed and that uses VMQ-capable network hardware. VMQ uses hardware packet filtering to deliver packet data from an external virtual machine network directly to virtual machines, which reduces the overhead of routing packets and copying them from the management operating system to the virtual machine. Windows Server 2012 introduces Dynamic Virtual Machine Queue (D-VMQ) for Hyper-V, which dynamically distributes the processing of incoming network traffic to host SQL Server processors, based on processor use and network load. In times of heavy network load, D-VMQ automatically uses more processors; when the network load decreases, D-VMQ relinquishes these processors.Without the VMQ technology and RSS, the majority of network processing burdens CPU0 and ultimately limits the scale of the solution. With D-VMQs, processor cores are dynamically assigned to distribute the workload.

2.2.4.2Single Root I/O Virtualization The Single Root I/O Virtualization standard was introduced by the PCI-SIG, the special interest group that owns and manages PCI specifications as open industry standards. SR-IOV helps to virtualize demanding workloads like SQL Server that require high network and I/O performance. It does so by helping virtual machines to perform I/O directly to the physical network adapter by bypassing the root partition. In Windows Server 2012, SR-IOV can be deployed in conjunction with key capabilities such as live migration to help high network performance with availability.SR-IOV provides the highest levels of networking performance for your virtualized SQL Server. Check with your hardware vendor for support because there may be a BIOS and firmware update required to help SR-IOV.

2.2.4.3QoS Bandwidth Management Quality of Service is a prioritization technique that gives the ability to cost effectively manage network traffic and enhance user experiences in enterprise environments. QoS allows you to meet the service requirements of a workload or application in a SQL Server environment by measuring network bandwidth, detecting changing network conditions (such as congestion or availability of bandwidth), and prioritizing or throttling network traffic. QoS provides features like bandwidth management, classification and tagging, priority-based flow control, policy-based QoS, and Hyper-V QoS. QoS bandwidth management helps to set a throttling rate for a workload like SQL Server. Both Minimum Bandwidth and Maximum Bandwidth help organizations to enforce predictable network throughput for SQL Server. Apart from bandwidth

716

management, organizations can prioritize and tag traffic so that QoS is enforced from end-to-end across a data center.

2.2.5SQL Virtual Machine Affinity ConsiderationsFor maintaining high availability of mission-critical applications, organizations can replicate their applications on different server workloads in different locations. Hyper-V with Windows Server 2012 provides Hyper-V Replica for replicating virtual machines from one location to another location. Service providers should consider using Virtual Machine Affinity rules to keep SQL Server virtual machines apart on hosts.

2.2.6Additional SQL Virtual Machine ConsiderationsTo improve SQL virtual machine performance, the following configurations should be applied to all SQL virtual machines:

Turnoff screensaver Set SQL virtual machine Power Scheme to High Performance Disable Windows IO Priority Management for SQL Server drives Consider using Windows Server Core

3 Multi-Tenant SQL Server Security DesignMulti-Tenant SQL reference architecture follows the same common identity framework described in this document (reference – TBD). The following diagram

717

depicts the conceptual architecture for the identity infrastructure.

In addition to follow the common identify framework, a set of design considerations and best practices for securing multi-tenant SQL Server will be described in this section.

3.1.1Surface Area ReductionSQL Server installation minimizes the "attack surface" because by default, optional features are not installed. During installation the administrator can choose to install:

Database Engineo SQL Server Replicationo Full-text and Semantic Extractions for Searcho Data Quality Services

Analysis Services Engine Reporting Services – Native and/or SharePoint Integration Services

718

Master Data Services Distributed Replay Server and Client Various Tools and Clients Documentation Components

It is a best practice to review which product features you actually need and install only those features. Later, install additional features only as needed. SQL Server has always been a feature-rich database and the number of updated features in SQL Server 2014 can be overwhelming. One way to make a system more secure is to limit the number of optional engine features that are installed and helpd by default. It is easier to help features when they are needed than it is to help everything by default and then turn off features that you do not need. This is the installation policy of SQL Server 2014, known as "off by default, help when needed." One way to ensure that security policies are followed is to make secure settings the default and make them easy to use.SQL Server 2014 contains a Policy-Based Management feature that makes it possible to define, deploy, and validate policy, and thereby enforce best practices. This feature subsumes and extends the SQL Server Surface Area Configuration tool that was introduced in SQL Server 2005. Although the Surface Area Configuration tool does not ship with SQL Server 2008 and above, Microsoft provides some predefined policies that correspond to the settings that were managed with the Surface Area Configuration tool. These policies are available as XML files and include:

Surface Area Configuration for Database Engine 2005 and 2000 Features Surface Area Configuration for Database Engine 2008 Features Surface Area Configuration for Service Broker Endpoints Surface Area Configuration for Analysis Services Features Surface Area Configuration for Reporting Services 2005 Features Surface Area Configuration for Reporting Services 2008 Features

Although there are other utilities (such as Services in Control Panel), server configuration commands (such as sp_configure), and APIs such as WMI (Windows Management Instrumentation) that you can use, the SQL Server Policy-Based Management combines this functionality into a single feature for ease-of-use. Policy-Based Management is usually configured through the graphic user interface, but can also be configured through system stored procedures or by using PowerShell scripts.SQL Server Policy Based Management’s Surface Area Configuration policies divide configuration into two subsets: endpoints and features. The database engine features included in the predefined policy are:

CLR Integration Remote use of a dedicated administrator connection

719

OLE Automation system procedures System procedures for Database Mail and SQL Mail (note: SQL Mail is no

longer supported in SQL Server 2014) Ad hoc remote queries (the OPENROWSET and OPENDATASOURCE functions) xp_cmdshell availability SQL Server Web Assistant (this was removed in SQL Server 2008)

You can use the SQL Server Configuration Manager tool to view the installed components of SQL Server and the client network interfaces. The startup type for each service (Automatic, Manual, or Disabled) and the server network interfaces that are available can be configured on a per-instance basis.Best practices for surface area reduction

Install only those components that you will immediately use. Additional components can always be installed as needed.

Enable only the optional features that you will immediately use. Review optional feature usage before doing an in-place upgrade and disable

unneeded features either before or after the upgrade. Develop a policy with respect to permitted network connectivity choices. Use

SQL Server Policy-Based Management to standardize this policy. Develop a policy for the usage of optional features. Use SQL Server Policy-

Based Management to standardize optional feature helping. Document any exceptions to the policy on a per-instance basis.

Turn off unneeded services by setting the service to either Manual startup or Disabled.

Configure only those server network interfaces that you will actually use.

3.1.2Policy-Based ManagementPolicy-Based Management can not only be used to manage and configure the Surface Area, but can also be used to detect out-of-compliance conditions, although there is no strong guarantee that it can stop any behavior that would put you out of compliance with the policy. In addition to the Surface Area Configuration policies mentioned previously, SQL Server 2014 includes a set of security best practices policies. These policies include:

Asymmetric Key Encryption Algorithm CmdExec Rights Secured Guest Permissions Public Not Granted Server Permissions SQL Server Login Mode SQL Server Password Expiration SQL Server Password Policy Symmetric Key Encryption for User Databases Symmetric Key for master Database

720

Symmetric Key for System Databases Trustworthy Database

You can implement these policies as-is, or customize them to enforce and insure compliance with your shop standards. SQL Server Policy-Based Management allows you to export and import policies using XML files and includes a PowerShell cmdlet that accomplishes the policy evaluation and can be used to script policy evaluation on a custom schedule. Best practices for policy-based management

Develop a policy for network connectivity, usage of optional features, and the implementation of SQL Server security best practices. Use SQL Server Policy-Based Management to standardize this policy.

Use Central Management Servers to standardize and enforce security policies across sets of servers in the enterprise.

Use Enterprise Policy Management Framework to consolidate history and reporting of sets of enterprise-wide policies.

3.1.3Service Account Selection and ManagementSQL Server 2014 implements as a set of Windows services. Each service can be configured to use its own service account. This facility is exposed at installation. SQL Server provides a special tool, SQL Server Configuration Manager, to manage these accounts. In addition, these accounts can be set programmatically through the SQL Server WMI Provider for Configuration Management. When you select a Windows account to be a SQL Server service account, you have a choice of:

Virtual Service account Managed Service account Domain user that is not a Windows administrator Local user that is not a Windows administrator Network Service account Local System account Local user that is a Windows administrator Domain user that is a Windows administrator

When choosing service accounts, consider the principle of least privilege. The service account should have exactly the privileges that it needs to do its job and no more privileges. You also need to consider account isolation; the service accounts should not only be different from one another, they should not be used by any other service on the same server. Only the first four account types in the list above (and Network Service account when running on Windows Server 2008 and above operating systems) have both of these properties. Making the SQL Server service account an administrator, at either a server level or a domain level, or using Local System, bestows too many unneeded privileges.

721

Windows Server 2008 R2 and Windows 7 operating systems introduced two updated types of service accounts: Virtual accounts and managed service accounts. SQL Server 2012 is the first version of SQL Server to permit these accounts to be used as service accounts. These are introduced to ensure isolation of windows services and to make provisioning, password management, and SPN configuration easier to manage. A managed service account is a special type of domain account that can be assigned to a single computer and used to manage a service. It must be provisioned by the domain administrator prior to being used. This type of account cannot be used to log in to a computer and provides automatic SPN and password management, once provisioned. Virtual accounts are managed local accounts that is automatically provisioned and managed. In SQL Server 2014, they are the default service account specified during setup. It can access the network. A virtual service account has a well-known name in the form of NT SERVICE\<SERVICENAME> and can access the network using the credentials <domain_name>\<computer_name>$. Windows Server 2008 and Windows Vista introduced per-service security identifiers (known as per-service SIDs). A per-service SID creates, in essence, an identity for each service which helps access control using the existing Windows access control model. Services can now apply explicit access control lists (ACL's) to resources that are private to the service - preventing other services as well as the user from accessing that resource.On a Windows 2008 R2 or Windows 7 operating system, managed service accounts and virtual service accounts are the best choices. With the introduction of Service SIDs in Windows Server 2008, Network Service is a good choice, and alleviates the need to change service passwords. Using a local user or domain user that is not a Windows administrator is also a good choice. If the server that is running SQL Server is part of a domain and must access domain resources such as file shares or uses linked server connections to other computers running SQL Server, a managed service account is the best choice. If the server is not part of a domain (for example, a server running in the perimeter network (also known as the DMZ) in a Web application) and does not need to access domain resources, a virtual account is preferred. If the service account needs additional privileges, the privilege should be granted to the appropriate Windows group, rather than granted directly to the service user account. This is consistent with the way access control lists are best managed in Windows in general. For example, the ability to use the SQL Server Instant File Initialization feature requires that the Perform Volume Maintenance Tasks user rights be set in the Group Policy Administration tool. This privilege should be granted to SQLServerMSASUser$computer_name$instance_name group for the “instance_name” instance of SQL Server Analysis Services on server "computer_name."

722

SQL Server service accounts should be changed only by using SQL Server Configuration Manager, or by using the equivalent functionality in the WMI APIs. Using Configuration Manager ensures that the updated service account is placed in the appropriate Windows group, and is thus granted exactly the correct privileges to run the service. In addition, using SQL Server Configuration Manager also re-encrypts the service master key that is using the updated account, although this happens automatically when SQL Server starts, thanks to a redundant copy of the service master key protected by DPAPI (machine key), even if the service account is changed from the Windows SCM. For more information on the service master key, see Encryption later in this paper. Because SQL Server service accounts also abide by Windows password expiration policies, it is necessary to change the service account passwords at regular intervals. The SQL Server Agent service account requires sysadmin privilege in the SQL Server instance that it is associated with. In SQL Server 2005 and above, SQL Server Agent job steps can be configured to use proxies that encapsulate alternate credentials. A CREDENTIAL is simply a database object that is a symbolic name for a Windows user and password. A single CREDENTIAL can be used with multiple SQL Server Agent proxies. To accommodate the principal of least privilege, do not give excessive privileges to the SQL Server Agent service account. Instead, use a proxy that corresponds to a CREDENTIAL that has just enough privilege to perform the required task. A CREDENTIAL can also be used to reduce the privilege for a specific task if the SQL Server Agent service account has been configured with more privileges than needed for the task. Proxies can be used for:

ActiveX scripting Operating system (CmdExec) Replication agents Analysis Services commands and queries SSIS package implementation (including maintenance plans) PowerShell

Best practices for SQL Server service accounts Use managed service accounts and virtual server accounts Always use SQL Server Configuration Manager to change service accounts. If you use a user or domain account, change the service account password at

regular intervals. Use CREDENTIALs to implement job steps that require specific privileges

rather than adjusting the privilege to the SQL Server Agent service account. If a user needs to implement a job that requires different Windows

credentials, assign them a proxy account that has just enough permissions to get the task done.

723

3.1.4Patching and Automatic Windows UpdateThe best way to ensure the security of the server software and to ensure the security of SQL Server 2014 is to install security hotfixes and service packs as soon as possible. Use manual updates on an operating system basis by using Windows Update or Microsoft Update. You can help automatic updates using Windows Update or Microsoft Update as well, but updates should be tested before they are applied to production systems. All hotfixes should be installed immediately and service packs should be tested and installed as soon as possible. This requirement cannot be emphasized enough. Best practices for patching SQL Server

Always stay as current as possible. Enable automatic updates whenever feasible but test them before applying

to production systems.

3.2 Encryption

3.2.1Data and Database EncryptionSQL Server 2014 has built-in data encryption, both at a cell level and encryption of an entire database. Data encryption at a cell level and is accomplished by means of built-in system procedures. Database-level data encryption (known as transparent data encryption or TDE) is accomplished by using DDL statements. TDE is an Enterprise version-only feature introduced in SQL Server 2008; cell level encryption has been around since SQL Server 2005.Encrypting data requires secure encryption keys and key management. A key management hierarchy is built into SQL Server. Each instance of SQL Server has a built-in service master key that is generated at installation; specifically, the first time that SQL Server is started after installation. The service master key is encrypted by using both the SQL Server Service account key and also the machine key. Both encryptions use the DPAPI (Data Protection API). A database administrator can define a database master key by using the following DDL.

CREATE MASTER KEY

WITH ENCRYPTION BY PASSWORD = '87(HyfdlkRM?_764#GRtj*(NS£”_+^$('

This key is actually encrypted and stored twice by default. Encryption that uses a password and storage in the database is required. Encryption that uses the service master key and storage in the master database is optional; it is useful to be able to automatically open the database master key without specifying the password. The service master key and database master keys can be backed up and restored separately from the rest of the database. In SQL Server 2014, the service and

724

database master keys use the AES_256 encryption algorithm; previous versions used Triple DES encryption.SQL Server also can use DDL to define certificates, asymmetric keys, and symmetric keys on a per-database basis. Certificates and asymmetric keys consist of a private key/public key pair. The public key can be used to encrypt data that can be decrypted only by using the private key. Or, for the sake of performance, the public key can be used to encrypt a hash that can be decrypted only by using the private key. Integrity check generation to ensure non-repudiation is known as signing. Alternatively, the private key can be used to encrypt data that can be decrypted by the receiver by using the public key. A symmetric key consists of a single key that is used for encryption and decryption. Symmetric keys are generally used for data encryption because they are orders of magnitude faster than asymmetric keys for encryption and decryption. However, distributing symmetric keys can be difficult because both parties must have the same copy of the key. In addition, it is not possible with symmetric key encryption to determine which user encrypted the data. Asymmetric keys can be used to encrypt and decrypt data but ordinarily they are used to encrypt and decrypt symmetric keys; the symmetric keys are used for the data encryption. This is the preferred way to encrypt data for the best security and performance. Symmetric keys can also be protected by individual passwords. SQL Server makes use of and also can generate X.509 certificates. A certificate is simply an asymmetric key pair with additional metadata, including a subject (the person the key is intended for), root certificate authority (who vouches for the certificate's authenticity), and expiration date. SQL Server generates self-signed certificates (SQL Server itself is the root certificate authority) with a default expiration date of one year. The expiration date and subject can be specified in the DDL statement. SQL Server does not use certificate revocation lists or the expiration date with data encryption. A certificate can be backed up and restored separately from the database; certificates, asymmetric keys, and symmetric keys are backed up with the database. In SQL Server 2014, when creating certificates from external sources, the maximum length of private keys imported from an external source is expanded from 3,456 to 4,096 bits. SQL Server 2014 also allowed the CREATE CERTIFICATE DDL statement to specify a FROM BINARY option to allow specifying the binary description of an ASN encoded certificate. The updated functions CERTENCODED and CERTPRIVATEKEY can be used to extract a binary description of an existing certificate, making certificates easier to deploy using DDL.A variety of block cipher encryption algorithms are supported, including DES, Triple DES, and AES (Rijndael) algorithms for symmetric keys and RSA for asymmetric keys. A variety of key strengths are supported for each algorithm. Stream cipher algorithms, such as RC4 and RC4_128 are supported only for backward compatibility when the database compatibility level is 90 or 100, and should not be used. User-defined algorithms are not supported. The key algorithm and key length

725

choice should be predicated on the sensitivity of the data. The HASHBYTES function in SQL Server 2014 supports the SHA2_256, and SHA2_512 algorithms in addition to hashing algorithms supported in previous SQL Server versions. The master database in SQL Server contains some built-in certificates with names that begin with “##MS_”. These certificates are used for system functionality and should not be deleted.As an alternative for some parts of the key management built into SQL Server, SQL Server 2008 introduced support for Extensible Key Management. Using Extensible Key Management (EKM) means that keys can be managed by an external source, such as a hardware security module. The external source is referred to in SQL Server as a cryptographic provider. TDE supports asymmetric keys that are provisioned by EKM. No other form of asymmetric key is supported by TDE and database certificates cannot currently be provisioned through EKM. EKM is supported for cell-level encryption through symmetric and asymmetric keys. It is highly recommended that you use EKM with both database-level and cell-level encryption for more comprehensive key management and hardware-based cryptography. Extensible Key Management is an Enterprise-version only feature.SQL Server can encrypt data on a cell level—data is specifically encrypted before it is stored into a column value and each row can use a different encryption key for a specific column. To use data encryption, a column must use the VARBINARY data type. The length of the column depends on the encryption algorithm used and the length of the data to be encrypted. The KEY_GUID of the key that is used for encryption is stored with the column value. When the data is decrypted, this KEY_GUID is checked against all open keys in the session. The data uses initialization vectors (also known as salted hashes). Because of this, it is not possible to determine if two values are identical by looking at the encrypted value. This means, for example, that I cannot determine all of the patients who have a diagnosis of Flu if I know that Patient A has a diagnosis of Flu. Although this means that data is more secure, it also means that you cannot use a column that is encrypted by using the data encryption routines in indexes, because data values are not comparable. SQL Server 2008 introduced database-level encryption as an adjunct and alternative to cell-level encryption. In addition, recent versions of the Microsoft Windows operating system (Windows Server 2008 and beyond and some versions of Windows Vista and Windows 7) provide disk volume encryption using BitLocker. Both TDE and BitLocker encrypt data as it in written to disk and decrypt data as it is read from disk. Either one can be added to the disk storage media without any change to the database. Access to the encrypted data in SQL Server is controlled through normal SQL Server permissions. Transparent Data Encryption encrypts data files, log files, tempdb, and database backups, but does not encrypt data stored using SQL Server’s FILESTREAM storage feature. BitLocker encrypts the entire volume, which would include FILESTREAM

726

storage and non-SQL Server database files. As a general rule, it probably makes more sense to use BitLocker on portable computers (even those without SQL Server) as it help protects the entire volume. If laptop data is compromised, presumably this happens due to physical access to the media and BitLocker help protects against this. On a server, however, it probably makes more sense to use SQL Server TDE. If a server storage volume is compromised, it is typically through network access and BitLocker does not help protect against this because when using TDE, the encryption is bound to the database files, not to the disk, in such a way that even if the database files are copied to another drive/tape, they will continue being encrypted. BitLocker is volume-bound, so copying to another disk would effectively copy a cleartext file.Enabling TDE on a database requires two keys: a database encryption key that uses symmetric key encryption to affect the encryption of the database and a certificate in the master database that helps protect the database encryption key. Because the certificate in the master database is needed to restore the database, care should be taken to back this certificate up. Data encryption is becoming more commonplace with some vendors and industries (for example, the payment card industry). Use data encryption only when it is required or for very high-value sensitive data. In some cases, encrypting the network channel or using SQL Server permissions is a better choice because of the complexity involved in managing keys and invoking encryption/decryption routines.Because unencrypted data must be stored in memory buffers before being transmitted to clients, it is impossible to keep data away from an administrator who has the ability to debug the process or to patch the server. Memory dumps can also be a source of unintended data leakage. If symmetric keys are protected by asymmetric keys and the asymmetric keys are encrypted by using the database master key, a database administrator could impersonate a user of encrypted data and access the data through the keys. If help protect from the database administrator is preferred, Extensible Key Management is the first choice, followed by encryption keys secured by passwords if EKM is not available, rather than by the database master key. To guard against data loss, encryption keys that are secured by passwords must have an associated disaster recovery policy (offsite storage, for example) in case of key loss. You can also require users to specify the database master key by dropping encryption of the database master key by the instance master key. Remember to back up the database in order to back up the symmetric keys, because there are no specific DDL statements to back up symmetric and asymmetric keys, just as there are specific DDL statements to back up certificates, the database master key, and the service master key.Best practices for data encryption

Encrypt high-value and sensitive data. Use symmetric keys to encrypt data, and asymmetric keys or certificates to

help protect the symmetric keys.

727

Password-help protect keys and remove master key encryption for the most secure configuration.

Do not delete pre-provisioned system certificates in the master database Always back up the service master key, database master keys, and

certificates by using the key-specific DDL statements. Always back up your database to back up your symmetric and asymmetric

keys. TDE is recommended for encrypting existing applications or for performance

sensitive applications. Cell-level encryption can be used for defense in depth both for a database

encrypted by TDE and for limited access control through the use of passwords.

Use EKM with both database-level and cell-level encryption for more comprehensive key management and hardware-based cryptography.

3.2.2SSL EncryptionSQL Server 2014 can use an encrypted channel for two reasons: to encrypt credentials for SQL logins, and to provide end-to-end encryption of entire sessions. Using encrypted sessions requires using a client API that supports these. The Microsoft OLE DB, ODBC, JDBC 1.2, and ADO.NET clients all support encrypted sessions. The other reason for using SSL is to encrypt credentials during the login process for SQL logins when a password is passed across the network. If an SSL certificate is installed in a SQL Server instance, that certificate is used for credential encryption. If an SSL certificate is not installed, SQL Server 2014 can generate a self-signed certificate and use this certificate instead. Using the self-signed certificate prevents passive man-in-the-middle attacks, in which the man-in-the-middle intercepts network traffic, but does not provide mutual authentication. Using an SSL certificate with a trusted root certificate authority prevents active man-in-the-middle attacks and provides mutual authentication. Bear in mind that the TDS protocol version that SQL Server uses is negotiable. Using an older version of TDS (e.g. older versions of FreeTDS) to connect to SQL Server may result in the encrypted channel for login not being used. Therefore, it is a best practice to always use modern drivers/providers with SQL Server.Best practices for SSL channel encryption

If you must support SQL logins, install an SSL certificate from a trusted certificate authority rather than using SQL Server 2008 self-signed certificates.

Use "allow only encrypted connections" only if needed for end-to-end encryption of sensitive sessions.

Do not use older TDS protocol versions; this ensures that SQL Login information is always encrypted.

728

3.3 Access Control

3.3.1Administrator PrivilegesBeginning in SQL Server 2008, SQL Server does not automatically grant the server's Administrators group (BUILTIN\administrators) the sysadmin server role. When installing SQL Server 2014, you are required to add at least one Windows login to the sysadmin role. This is true for SQL Server Analysis Services as well as the database engine.For accountability in the database, avoid relying on the Administrators group and add only specific database administrators to the sysadmin role. Another option is to have a specific DatabaseAdministrators role at the operating system level. Minimizing the number of administrators who have sysadmin or CONTROL SERVER privilege also makes it easier to resolve problems; fewer logins with administrator privilege means fewer people to check with if things go wrong. The permission VIEW SERVER STATE is useful for allowing administrators and troubleshooters to view server information (dynamic management views) without granting full sysadmin or CONTROL SERVER permission.Best practices for administrator privileges

Use administrator privileges only when needed. Minimize the number of administrators. Have multiple distinct administrators if more than one is needed. Avoid dependency on the builtin\administrators Windows group.

3.3.2User-Defined Server RolesSQL Server 2012 introduces user-defined server roles, which can function in an analogous way to user-defined database roles, but with server-level securables. This allows you to collect sets of permissions and assign them a role, rather than granting them to individual users. Any server-level permission, such as CREATE ANY DATABASE, ALTER ANY DATABASE, CONNECT SQL, or SHUTDOWN can be granted to a server role. Using user-defined server roles rather than granting access to individuals, should be considered a best practice.

3.3.3Database Ownership and TrustA SQL Server instance can contain multiple user databases. Each user database has a specific owner; the owner defaults to the database creator. By definition, members of the sysadmin server role (including system administrators if they have access to SQL Server through their default group account) are database owners (DBOs) in every user database. In addition, there is a database role, db_owner, in

729

every user database. Members of the db_owner role have approximately the same privileges as the dbo user.If each database is owned and managed by the same general entity, it is still not a good practice to establish a "trust relationship" with a database unless an application-specific feature, such as cross-database Service Broker communication, is required. A trust relationship between databases can be established by allowing cross-database ownership chaining or by marking a database as trusted by the instance by using the TRUSTWORTHY property. An example of setting the TRUSTWORTHY property follows:

ALTER DATABASE pubs SET TRUSTWORTHY OFF

Enabling the TRUSTWORTHY property may open an Elevation of Privilege path from DBO to sysadmin (depending on the permissions of the DBO for that database), therefore it is highly recommended to not help the TRUSTWORTHY property on any user-defined database that is owned by a sysadmin.

Best practices for database ownership and trust Use user-defined server roles as an alternative to assigning server-level

privileges to individual users. Leverage contained database Confer trust selectively. Leave the Cross-Database Ownership Chaining setting off unless multiple

databases are deployed at a single unit. Migrate usage to selective trust instead of using the TRUSTWORTHY property.

3.3.4Lockdown of System Stored ProceduresSQL Server uses system stored procedures to accomplish some administrative tasks. These procedures almost always begin with the prefix xp_ or sp_. Even with the introduction of standard DDL for some tasks (for example, creating logins and users), system procedures remain the only way to accomplish tasks such as sending mail or invoking COM components. System extended stored procedures in particular are used to access resources outside the SQL Server instance. Most system stored procedures contain the relevant security checks as part of the procedure and also perform impersonation so that they run as the Windows login that invoked the procedure. Because some system procedures interact with the operating system or implement code outside of the normal SQL Server permissions, they can constitute a security risk. System stored procedures such as xp_cmdshell or sp_send_dbmail are off by default and should remain disabled unless there is a reason to use them. In SQL Server 2005 and above, you no longer need to use stored procedures that access

730

the underlying operating system or network outside of the SQL Server permission space. SQLCLR procedures implementing in EXTERNAL_ACCESS mode are subject to SQL Server permissions, and SQLCLR procedures implementing in UNSAFE mode are subject to some, but not all, security checks. For example, to catalog a SQLCLR assembly categorized as EXTERNAL_ACCESS or UNSAFE, either the database must be marked as TRUSTWORTHY (see Database Ownership and Trust) or the assembly must be signed with a certificate or asymmetric key that is cataloged to the master database. SQLCLR procedures should replace user-written extended stored procedures in the future.Some categories of system stored procedures can be managed by using SQL Server Policy-Based Management. These include:

xp_cmdshell - implements a command in the underlying operating system Database Mail procedures SQL Mail procedures (SQL Mail is removed in SQL Server 2012) COM component procedures (e.g. sp_OACreate)

Enable these procedures only if necessary.The system stored procedures should not be dropped from the database; dropping these can cause problems when applying service packs. Removing the system stored procedures results in an unsupported configuration. It is usually unnecessary to completely DENY all users access to the system stored procedures, as these stored procedures have the appropriate permission checks internal to the procedure as well as external.Best practices for system stored procedures

Disable xp_cmdshell unless it is absolutely needed. Disable COM components once all COM components have been converted to

SQLCLR. Disable both mail procedures (Database Mail and SQL Mail) unless you need

to send mail from SQL Server. Prefer Database Mail as soon as you can convert to it.

Use Policy-Based Management to enforce a standard policy for extended procedure usage.

Document each exception to the standard policy. Do not remove the system stored procedures by dropping them. Do not modify the default permissions on system objects. Do not DENY all users/administrators access to the extended procedures.

3.4 Authentication

731

3.4.1Authentication Modes and LoginsSQL Server has two authentication modes: Windows Authentication and Mixed Mode Authentication. In Windows Authentication mode, specific Windows user and group accounts are trusted to log in to SQL Server. Windows credentials are used in the process; that is, either Kerberos or NTLM authentication credentials. SQL Server 2008 can use Kerberos authentication with all protocols; previous versions only used Kerberos with the TCP/IP protocol. Windows accounts use a series of encrypted messages to authenticate to SQL Server; no passwords are passed across the network during the authentication process. In Mixed Mode Authentication, both Windows accounts and SQL Server-specific accounts (known as SQL logins) are permitted. When SQL logins are used, SQL login passwords are passed across the network for authentication. This makes SQL logins less secure than Windows logins.It is a best practice to use only Windows logins whenever possible. Using Windows logins with SQL Server achieves single sign-on and simplifies login administration. Password management uses the ordinary Windows password policies and password change APIs. Users, groups, and passwords are managed by system administrators; SQL Server database administrators are only concerned with which users and groups are allowed access to SQL Server and with authorization management. SQL logins should be confined to legacy applications, mostly in cases where the application is purchased from a third-party vendor and the authentication cannot be changed. Other uses for SQL logins are with cross-platform client-server applications in which the non-Windows clients do not possess Windows logins and applications that require logins from untrusted domains. Although using SQL logins is discouraged, there are security improvements for SQL logins in SQL Server 2005 and later. These improvements include the ability to have SQL logins use the password policy of the underlying operating system and better encryption when SQL passwords are passed over the network. We'll discuss each of these later in the paper.Using the CREATE LOGIN statement is preferred; the sp_addlogin and sp_grantlogin system stored procedures are supported for backward compatibility only. SQL Server 2005 and above also provide the ability to disable a login or change a login name by using the ALTER LOGIN DDL statement. For example, Use ALTER LOGIN rather than the procedures sp_denylogin or sp_revokelogin, which are supported for backward compatibility only.If you install SQL Server in Windows Authentication mode, the sa login account is disabled and a random password is generated for it. If you later need to change to Mixed Mode Authentication and re-help the sa login account, you will not know the password. Change the sa password to a known value after installation if you think you might ever need to use it.

732

SQL Server contains some pre-defined logins such as NT AUTHORITY\SYSTEM and ##MS_PolicyEventProcessingLogin##. These logins are used for SQL Server built-in functionality and should not be deleted. Logins can be based on Windows Groups in addition to being based on Windows Users. Using Windows Logins instead of Windows Group provides the ability to identify individual Windows Users for tracking purposes. Also, because a SQL Server login is tied to a default database and default language, if Windows Groups are used for logins and a Windows Users is a member of multiple Windows Groups with SQL Server logins, the default database and default language is determined by using the Windows Group with the highest principal_id. Therefore, attempt to keep Windows Group logins relatively consistent with respect to default database and language, if users can belong to multiple groups.Logon Triggers provide extra control of access to the database by allowing custom actions during the login process.Best practices for authentication mode and logins

Always use Windows Authentication mode if possible. Use Mixed Mode Authentication only for legacy applications, non-Windows

users, and users from untrusted domains. Use the standard login DDL statements instead of the compatibility system

procedures. It the sa account is not going to be used, you should disable it. Change the

sa account password to a known value if you might ever need to use it. Always use a strong password for the sa account and change the sa account password periodically.

Do not manage SQL Server by using the sa login account; assign sysadmin privilege to a knows user or group.

Rename the sa account to a different account name to prevent attacks on the sa account by name.

Do not delete internal built-in logins Use Windows Logins rather than Windows Group to control access to SQL

Server and use care when using Windows Group logins to prevent group overlap for a particular user.

Use login triggers for more granular control of the login process.

3.4.2Contained Databases and AuthenticationSQL Server 2012 introduced the concept of contained databases. A contained database is a database that includes all of the settings and metadata needed for its operation with dependencies on the instance. From a security perspective, a contained database makes it easier to have user accounts that are limited to a single database. SQL Server 2014 supports partially contained databases; it does

733

not yet support full containment. Although contained databases allow more control by the “application administrator” they do have security repercussions.Contained databases are interesting for a security point of view in that they allow defining users with authentication privileges, i.e. users who can log directly into a contained database without a corresponding login. Contained databases support two types of users: Windows users and groups that can directly connect to the database and do not need logins, and users with a password where the password is authenticated by the database, not the instance. This is not permitted by default; the instance administrator must specifically allow it by setting the “contained database authentication” configuration option on. To disallow connections to specific contained databases but allow access to other contained databases, a login trigger can be used. Allowing direct connection of users to a database changes the effective threat-level of some existing permissions. For example, the permission ALTER ANY USER in a contained database gives permission to add user-based access to an instance through a contained database. Logins with ALTER ANY DATABASE or CONTROL DATABASE permission could also set containment on a database and add instance access through users. In addition, contained database users can connect to other database in the instance if the guest account is enabled.Although you can use the system stored procedure sp_migrate_user_to_contained to migrate a database user mapped to a SQL login to a contained database user-with-password, contained databases’ user-with-password does not use password history and expiration policies as SQL logins do, although password complexity checks are still used. Therefore, attaching a contained database could allow weak passwords. In addition, the password hashes for these passwords are stored in the database, not in master. Anyone with access to the database file could perform a dictionary attack on a separate, unaudited instance.There exists the possibility of conflicts, if a login and contained database user have the same name. The rule for resolving this conflict is that if an initial catalog is specified in the connection string and it’s the contained database, access is checking against the user based principal, not the login. To ameliorate this possibility, do not create conflicting names or specify a contained database as an initial catalog in a connection string. In addition, members of the sysadmin role should not use initial catalog in a connection string.Best practices for contained databases

Use the default (off) setting for contained database authentication and only turn this setting on if it is required.

Protect backups of contained databases using passwords. Audit the capabilities of users and modules in contained databases. Audit logins that have the ability to set containment, if contained database

authentication is allowed.

734

Disable the guest account on databases that share an instance with contained databases.

Take care to avoid login/user-with-login naming conflicts Avoid connection strings with initial catalog if contained database

authentication is permitted.

3.5 Network SecurityA standard network protocol is required to connect to the SQL Server database. There are no internal connections that bypass the network. As part of SQL Server 2014 installation, a warning message will occur if Windows Firewall is not helpd on the server machine. It is a general network security best practice to help Windows Firewall and restrict network protocols and ports to the minimum necessary for SQL Server operation.SQL Server 2005 introduced an abstraction for managing any connectivity channel—entry points into a SQL Server instance are all represented as endpoints. Endpoints exist for the following network client connectivity protocols:

Shared Memory Named Pipes TCP/IP Dedicated administrator connection

In addition, endpoints may be defined to permit access to the SQL Server instance for:

Service Broker Database mirroring

Following is an example of creating an endpoint for Service Broker.

CREATE ENDPOINT BrokerEndpoint_SQLDEV01

AS TCP

( LISTENER_PORT = 4022 )

FOR SERVICE_BROKER

( AUTHENTICATION = WINDOWS )

In keeping with the general policy of "off by default, help only when needed," no Service Broker, HTTP, or database mirroring endpoints are created when SQL Server 2014 is installed. The dedicated administrator connection (DAC) that was added in SQL Server 2005 is available only locally by default, although it can be

735

made available remotely. Access to database endpoints requires the login principal to have CONNECT permission. By default, no login account has CONNECT permission to Service Broker or HTTP Web Services endpoints. This restricts access paths and blocks some known attack vectors. It is a best practice to help only those protocols that are needed. For example, if TCP/IP is sufficient, there is no need to help the Named Pipes protocol.Additional ports are required to help NETBIOS protocol (UDP/137, UDP/138, and TCP/139) and SMB (Server Message Block) protocol (TCP/139 and TCP/445). These should be disabled by default on a machine running SQL Server unless they are needed. SMB is needed if using an SMB File Share as a storage option, e.g. in a cluster or when using the SQL Server Filestream/FileTable feature with remote Win32 access helpd. Although endpoint administration can be accomplished via DDL, the administration process is made easier and policy can be made more uniform by using the SQL Server Configuration Manager tool and Policy-Based Management. SQL Server Configuration Manager provides granular configuration of server protocols. With SQL Server Configuration Manager, you can:

Choose a certificate for SSL encryption. Allow only encryption connections from clients. Hide an instance of SQL Server from the server enumeration APIs. Enable and disable TCP/IP, Shared Memory, and Named Pipes protocols. Configure the name of the pipe each instance of SQL Server will use. Configure a TCP/IP port number that each instance listens on for TCP/IP

connections. Choose whether to use TCP/IP dynamic port assignment for named instances. Configure Extended Protection for both service binding and channel binding

in SQL Server 2014

The dialog for configuring TCP/IP address properties such as port numbers and dynamic port assignment is shown in Figure 1.

736

Figure 1 TCP/IP Addresses configuration page in SQL Server Configuration Manager

In SQL Server 2014, you can GRANT, REVOKE, or DENY permission to CONNECT to a specific endpoint on a per-login basis. By default, all logins are GRANTed permission on the Shared Memory, Named Pipes, and TCP/IP endpoints. You must specifically GRANT users CONNECT permission to other endpoints; no users are GRANTed this privilege by default. An example of granting this permission is:

GRANT CONNECT ON MyHTTPEndpoint TO MyDomain\Accounting

Best practices for network connectivity Enable Windows Firewall and limit the network protocols supported. Do not help network protocols unless they are needed. Disable NETBIOS and SMB protocol unless specifically needed. Do not expose a server that is running SQL Server to the public Internet. Configure named instances of SQL Server to use specific port assignments for

TCP/IP rather than dynamic ports.

737

Use extended help protect in SQL Server 2014 if the client and operating system support it.

Grant CONNECT permission only on endpoints to logins that need to use them. Explicitly deny CONNECT permission to endpoints that are not needed by users or groups.

3.6 Auditing SQL Server 2014 expands on the native auditing in the database engine added in SQL Server 2008. The SQL Server Audit feature maintains all the capabilities of the SQL Server 2005 auditing solutions and provides enhancements such as flexibility in audit data targets and granular auditing. In SQL Server 2014, Server Audit Specification is available in any edition of SQL Server, but SQL Server Database Audit Specification is available as an enterprise-only feature, although you can use Server Audit Specifications to audit all database-level events. Database Audit Specifications add the ability to do more granular auditing; to audit events from a particular user or schema for example. Earlier versions of SQL Server support login auditing, trigger-based auditing, and event auditing by using a built-in trace facility.The SQL Server Audit feature is meant to replace trace-based auditing as the preferred auditing solution. This feature was designed with the following goals in mind:

Security – The audit feature, and its objects, must be truly secure. Performance - Performance impact must be minimized. Management – The audit feature must be easy to manage. Discoverability - Audit-centric questions must be easy to answer.

SQL Server 2014 Audit can use a file as an auditing target but can also audit to the Windows Application Log or Windows Security Log. The Windows Security log is considered to be resistant to tampering and nonrepudiation, although its usage is generally controlled by a group policy object. Auditing to the Windows Security also helps integration with the Audit Collection Service (ACS) of the Microsoft System Center Operations Manager, which can securely collect audit information from the security logs of multiple machines and generate consolidated reports. SQL Server Audit metadata is defined using DDL and therefore can be managed using standard SQL Server permissions. Changes to the audit metadata, as well as helping and disabling audit sessions, are also audited.If SQL Server Audit is unable to write its audit events to the audit target, you can configure the audit object to shut down the server instance. This is necessary for meeting requirements of the Common Criteria to ensure that the server cannot operate without its activity being audited. In SQL Server 2014, you can also

738

configure the audit object to fail the database operation associated with the audit object, but not shutdown the server. This allows maximum availability because un-audited operations continue to work. Additional implementation enhancements make auditing in SQL Server 2014 more resilient to transient network failures. If the instance cannot start because of a SQL Server Audit, it can be brought up using the –m or –f trace flags in order to issue the audit DDL necessary to fix the problem with auditing.SQL Server Audit uses the Extended Events feature to minimize impact on performance. Extended Events are events that are built into the SQL Server code to have minimal impact. Audits can be written synchronously or asynchronously, with a configurable queue delay to accommodate a trade-off between database performance and possible audit record loss. Another way to minimize performance impact is to use more granular auditing. This feature, using Database Audit Specifications, is an Enterprise-only feature. SQL Server Audit allows defining audits at a database object and database login/user level, as well as providing a number of audit groups for convenience. At this time, auditing cannot be done at the column level. In SQL Server 2014, you can also audit user-defined audit events. These events are invoked by the application using the sp_audit_write system stored procedure.Auditing information is stored in binary when written to file targets and can be read with a table-valued function fn_get_audit_file(). Because access is through this table-valued function, it is easy to select and report on audit information using ordinary Transact-SQL code. Audit information written to the Windows log can be read using any of the Windows log-reading utilities, such as Windows Event Viewer. Both file and Windows log-based auditing information can also be read directly with SQL Server Management Studio.Password policy compliance is automatically enforceable through policy in SQL Server for both Windows logins and SQL logins. Login auditing is available by using an instance-level configuration parameter. Auditing failed logins is the default, but you can specify to audit all logins. Although auditing all logins increases overhead, you may be able to deduce patterns of multiple failed logins followed by a successful login, and use this information to detect a possible login security breech. Auditing is provided on a wide variety of events including Add Database User, Add Login, DBCC events, Change Password, GDR events (Grant/Deny/Revoke events), and Server Principal Impersonation events. To audit security events, use event-based auditing, specifically the events in the security audit event category. Event-based auditing can be trace-based, or event notifications-based. Trace-based event auditing is easier to configure, but may result in a large event logs, if many events are traced. On the other hand, event notifications send queued messages to Service Broker queues that are in-database objects. Trace-based event auditing cannot trace all events; some events, such as SQL:StmtComplete events, are not available when using event notifications.

739

http://msdn2.microsoft.com/en-us/library/ms191148.aspx

There is a WMI provider for events that can be used in conjunction with SQL Server Agent alerts. This mechanism provides immediate notification through the Alert system that a specific event has occurred. To use the WMI provider, select a WMI-based alert and provide a WQL query that produces the event that you want to cause the alert. WQL queries use the same syntax for naming as does event notifications. An example of a WQL query that looks for database principal impersonation changes would be:

SELECT * FROM AUDIT_DATABASE_PRINCIPAL_IMPERSONATION_EVENT

SQL Server can be configured to support auditing that is compliant with C2 certification under the Trusted Database Interpretation (TDI) of the Trusted Computer System Evaluation Criteria (TCSEC) of the United States National Security Agency. This is known as C2 auditing. C2 auditing is configured on an instance level by using the C2 audit mode configuration option in sp_configure. A Microsoft-supplied auditing script also needs to be run to set up profiler-based auditing. This script is available at the Microsoft download center at http://download.microsoft.com/download/9/5/F/95FDD106-4E98-47B4-B676-7FDB9A403AF0/SQL_Server2008_EAL1_trace.sql.When C2 or Common Criteria auditing is enabled, data is saved in a log file in the Data subdirectory in the directory in which SQL Server is installed. The initial log file size for C2 auditing is 200 megabytes. When this file is full, another 200 megabytes is allocated. If the volume on which the log file is stored runs out of space, SQL Server shuts down until sufficient space is available or until the system is manually started without auditing. Ensure that there is sufficient space available before helping C2 auditing and put a procedure in place for archiving the log files. This script may be changed to use the SQL Server audit feature when SQL Server 2012 is Common Criteria certified.Best practices for auditing

Auditing is scenario-specific. Balance the need for auditing with the overhead of generating addition data.

Use the SQL Server 2014 Audit feature for the most secure and granular auditing.

Audit successful logins in addition to unsuccessful logins if you store highly sensitive data.

Audit DDL and specific server events by using trace events or event notifications.

DML can be audited by using trace events or SQL Server Audit. Use WMI to be alerted of emergency events.

740

http://download.microsoft.com/download/9/5/F/95FDD106-4E98-47B4-B676-7FDB9A403AF0/SQL_Server2008_EAL1_trace.sql

http://download.microsoft.com/download/9/5/F/95FDD106-4E98-47B4-B676-7FDB9A403AF0/SQL_Server2008_EAL1_trace.sql

4 Multi-Tenant SQL Server High Availability and Disaster Recovery Design

High availability (HA) may be defined in a service-level agreement (SLA) as the percentage of uptime a hosting company guarantees a customer; minimizing unscheduled downtime, with an agreed-upon sacrifice in performance, if necessary, to keep multiple servers in sync. Disaster recovery (DR) may be defined as a plan the hosting company uses with the customer’s consent to recover from a data center failure, when access to a data center is cut off because of a power failure, natural disaster, etc. The customer’s data must be brought back online from a different data center as quickly as possible with as little data loss as possible.

SQL Server 2014 AlwaysOn solutions provide redundancy across servers and across data centers. Planned and unplanned downtimes are minimized. The administrator has updated client tools to make deploying, monitoring, and managing HA and DR solutions easier. SQL Server 2014 AlwaysOn solutions include:

AlwaysOn Failover Cluster Instances AlwaysOn Availability Groups Availability Group Listeners Read-only Secondary Replicas and Application Intent

741

Using these solutions, service providers can offer their customers a variety of HA and DR designs. AlwaysOn Failover Cluster Instances can be used for both HA and DR. Entire SQL Server instances fail over from one node to another. Flexible rules can be implemented that determine when the primary node is not healthy and when automatic failover should occur. For example, secondary nodes detect when the primary node has failed. Rules can restrict votes to nodes within a data center, so a network failure does not trigger a failover. Local failover clusters provide HA within a data center, helping protect against server failure. Nodes are directly connected to shared storage or share a SAN. Microsoft also offers the iSCSI Software Target over the network by turning a Windows Server computer into a storage device. This can be used as shared storage for a failover cluster, reducing the expense for the service provider versus the setup costs of a SAN. With multisite clustering of a SQL Server instance, cluster nodes can be located on different subnets or use virtual LANs. Failover can now be across distances, with more flexible failover policies. Low-level infrastructure such as SAN replication and a sufficiently fast connection are required to keep storage entities in sync. This takes clustering beyond the HA role and into the DR role with failover now helping protect against data center failure. AlwaysOn Availability Groups can also be used for both HA and DR by maintaining a set of databases, synchronously or asynchronously, in different locations. The databases are not hardware-dependent, so the service provider has the flexibility of using a wider variety of hardware and can make use of more available resources. Availability groups roll database mirroring and log shipping into a single solution, reducing maintenance overhead for the administrator. AlwaysOn HA and DR features are available starting in the SQL Server 2014 Enterprise Edition. Note: Database mirroring was deprecated as of SQL Server 2012 and will be removed from a future version of SQL Server. Availability groups are intended to replace database mirroring starting with SQL Server 2012. Each availability group contains a defined set of databases known as replicas. A single primary replica writes to a set of up to four secondary replicas. Writes are synchronous or asynchronous. Synchronous writes can occur on up to two secondary replicas. A synchronous write means that a transaction does not commit on the primary replica until its success is guaranteed on all secondary replicas where synchronous writes are specified. An asynchronous write takes place some milliseconds after a transaction commits. If a server or a data center is lost, automatic failover can occur to one secondary replica where synchronous writes occur. Manual failover can occur to any replica.

742

If a failure occurs on the primary replica before the write occurs on an asynchronous secondary replica, there can be some data loss, just as with asynchronous database mirroring or log shipping. The advantage to taking the small risk inherent in asynchronous commits is that the primary replica is not waiting for writes to these servers and can release locks and process other reads and writes faster. This is especially helpful where a fast connection does not exist between the primary replica and a secondary. Availability group listeners are a network end point for an availability group. They allow clients to connect to the primary replica with a single network name, IP address, and TCP port. A listener also connects to a secondary replica when configured for read-only secondary replicas. When a failover occurs, there is no need for the client to know the network name of the secondary replica that is the updated primary replica. Listeners fail over as the primary replica fails over. Read-Only Secondary Replicas and Application Intent allow clients to use secondary replicas for read-only purposes, such as reporting and backups. A client can connect to a read-only secondary replica by specifying an application intent attribute in a Microsoft .NET connection string when connecting to the listener. The listener routes the client connection to an appropriate secondary replica.

4.1 Network Configuration

743

All nodes of a failover cluster instance must be in the same domain. Every server should have the same domain role, that of a member server. SQL Server Failover Cluster Instances are not supported on domain controllers. All cluster nodes should use the same domain account to log on to the network. Likewise, each SQL Server instance should use the same domain account. Network names and IP addresses are assigned to the following resources. Network names must be unique in the domain. SQL Server 2014 supports IPv6.

The name of the SQL Server Failover Cluster Instance. This is the virtual server name which clients will use to connect to SQL Server. It is not the same thing as a SQL Server named instance (see below).

The name of each cluster node. The name of the failover cluster.

If connecting to a default instance of SQL Server, the client does not have to supply a named instance name. When connecting to a named instance, the client must furnish the named instance name as part of the connection string along with the network name or IP address assigned to the SQL Server Failover Cluster Instance or SQL Server Availability Group. The administrator assigns the instance name during SQL Server setup. Instance names do not have to be unique in the domain, only to the server hosting the SQL Server instance. In the case of a cluster, the named instance name is assigned to all failover cluster instances on all nodes. Administrators should use caution when assigning SQL Server named instance names. To change one requires uninstalling and reinstalling SQL Server. An instance ID is also supplied during SQL Server setup. This defaults to MSSQLSERVER for the default instance or the named instance. The instance ID is used to identify the instance of SQL Server in a directory tree or in the registry. Like the named instance name, the instance ID cannot be changed without reinstalling SQL Server. You can also assign a static TCP port for the SQL Server instance that clients will use to connect. SQL Server uses port 1433 by default. If there is more than one instance of SQL Server using the same network name and IP address, one should either be assigned a different static port, or SQL Server can assign a dynamic port. Clients can connect to the server using UDP port 1434 to get the TCP port they should use for the specified instance from the SQL Server Browser service. An administrator would typically assign the default port 1433 to the default instance and use a different static port or dynamic port assignment with named instances. The SQL Server Browser service is not a cluster resource and does not fail over. It must run on each node of the cluster. On clusters, the service listens on IP_ANY.

744

SQL Server 2014 supports nodes for a single failover cluster instance in different subnets. As with previous versions of SQL Server, you can also create a Stretch Virtual Local Area Network (LAN) (VLAN) to expose a single IP address. In previous versions of SQL Server, during startup SQL Server iterates through all IP addresses assigned to the SQL Server Failover Cluster Instance and attempts to bind all of them. If any binding fails, the SQL Server startup fails. Starting with SQL Server 2014, when adding a node, SQL Server Setup detects a multi-subnet installation and specifies an IP address resource dependency of OR so that a SQL Server can be online when there is at least one IP address it can bind to.

4.2 Quorum Configuration Quorum configuration is a necessary part of cluster configuration. For both failover cluster instances and availability groups, the health of the cluster node and the SQL Server services are constantly monitored by the other nodes. Part of installation and configuration of a cluster will be to establish the quorum rules for when an automatic failover should occur, at the cluster node level, the SQL Server FCI level, and the availability group level. If a node or the SQL Server instance on a node is unresponsive, the node is considered to have failed. A node is considered healthy only if a quorum of other nodes in the cluster votes to consider it healthy. Part of the quorum configuration is to establish the methodology for voting and what constitutes failure. For example, if all nodes are in a single data center using shared storage, all nodes by default all nodes have a vote. If the cluster is configured across data centers, an administrator may wish to configure the cluster so that nodes in a separate data center do not have a vote. This will prevent a network failure across data centers from triggering a failover. For availability groups using asymmetric storage, Microsoft recommends the Node Majority quorum mode when there is an odd number of voting nodes, and the File Share Majority mode when there is an even number of voting nodes.

4.3 SQL Server System Data and Availability Groups An availability group replica does not contain system metadata by default. Data such as login IDs, server roles, and server-level permissions are contained in each Master database of each SQL Server instance. An administrator must prepare each secondary replica with the necessary system data manually or must make the availability group databases contained databases. Contained databases are a SQL Server 2014 feature allowing system metadata to

745

be stored in user databases, reducing their dependency on the Master database and reducing cross-server administration. If you elect not to use contained databases, you will have to transfer login IDs and passwords from the primary replica SQL Server to the secondary replica SQL Servers. For more information, see How to transfer logins and passwords between instances of SQL Server.

4.3.1Jobs, Alerts, Email Operators Transfer any jobs, schedules, alerts, and operators from the primary replica that will need to run on the secondary replicas. The secondary replicas are read-only, but you may choose to perform full database backups and transaction log backups on them as well as reporting. There is a SQL Server Integration Services (SSIS) Transfer Jobs task just for this purpose. This will require some development work, setting up the task with a source and destination Connection Manager. For more information, see Transfer Jobs Task. You can also use Windows PowerShell to script SQL Server Agent jobs. On the secondary replicas, the SQL Server Agent service should be configured using a Windows domain user account that is a member of the sysadmin fixed server role in the SQL Server instance. It is a best practice to use the same account for all SQL Server Agent instances in the availability group. The SQL Server Agent service should not be configured to auto-restart SQL Server or the SQL Server Agent service on a failover cluster instance.

4.3.2Backups SQL Server Availability Groups, though they use the transaction log to transfer data between replicas, do not take the place of SQL Server backups. There should be periodic full database backups, optionally differential backups, and transaction log backups in each replica database the same as any other production database. When the transaction log is backed up, it is truncated—and the space occupied by the backed up data is available for updated transactions. If the transaction log is not backed up periodically, it will continue to grow and consume storage. You have the option of doing backups on read-only replicas in order to minimize resource consumption on the primary replica. See Read-Only Secondary Replicas and Application Intent, below. Backups from designated replicas can still form a complete backup and restore chain.

746

5 Shared Database Multi-Tenancy Model Design Considerations

Since the shared Database multi-tenancy model is sharing the same SQL Server instance, and each tenant is isolated at database level. The following design considerations will be applied while designing the multi-tenant SQL Server environment.

5.1 Resource GovernorSQL Server Resource Governor was introduced in Microsoft SQL Server 2008 Enterprise as a way to provide multi-tenancy and resource isolation for single SQL Server instances serving multiple client workloads. The Resource Governor feature allows you to set limits on the amount of memory and CPU resources incoming requests can use, and it provides a way to isolate and limit runaway queries, adding fine-grained resource tracking for chargeback and delivering predictable performance.With SQL Server 2014 you can provide more complete isolation of CPU resources for workloads and put caps on CPU usage for a higher level of predictability, you can control a greater proportion of SQL Server memory allocations, and also control SQL IO resource consumptions.

5.1.1Resource Pools, Workload Groups, and ClassificationSQL Server Resource Governor introduced the concept of resource pools as a fundamental implementation of resource isolation within a SQL Server instance. Resource pools are controlled with Transact-SQL and other management interfaces such as SMO, and they can be assigned minimum and maximum CPU and memory resources through the CREATE RESOURCE POOL and ALTER RESOURCE POOL statementsSQL Server 2014 supports up to 62 user-definable pools. There are also two built-in resource pools: one called internal which is reserved for system tasks and is not configurable, and a user-configurable pool called default where workloads will run by default.Note: Even SQL Server 2014 supports up to 62 user-defined resource pools, the recommended maximum number of resource pools should be created is 18 if the CPU cap is used since the minimum increment of CPU should be 5%.Each user resource pool can be associated with one or more workload groups, which are logical entities that represent one or more client workloads. Incoming sessions can be associated with these workload groups by way of a user definable Classifier

747

http://msdn.microsoft.com/en-us/library/ms162169.aspx

function which runs after login and can call system functions to evaluate various login properties such as user name, workstation name, database name. The following diagram shows how these components fit together to classify incoming connections into resource pools.

5.2 Database Storage To control each tenant’s database storage size, Windows File Server Resource Manager should be implemented to leverage its Quota management capabilities.File Server Resource Manager is a set of features that allow you to manage and classify data that is stored on file servers. File Server Resource Manager includes the following features:

File Classification Infrastructure File Classification Infrastructure provides insight into your data by automating classification processes so that you can manage your data more effectively. You can classify files and apply policies based on this classification. Example policies include dynamic access control for restricting access to files, file encryption, and file expiration. Files can be classified automatically by using file classification rules or manually by modifying the properties of a selected file or folder.

File Management Tasks File Management Tasks helps you to apply a conditional policy or action to files based on their classification. The conditions of a file management task include the file location, the classification properties, the date the file was created, the last modified date of the file, or the last time the file was accessed. The actions that a file

748

management task can take include the ability to expire files, encrypt files, or run a custom command.

Quota management Quotas allow you to limit the space that is allowed for a volume or folder, and they can be automatically applied to updated folders that are created on a volume. You can also define quota templates that can be applied to updated volumes or folders.

File screening management File screens help you control the types of files that user can store on a file server. You can limit the extension that can be stored on your shared files. For example, you can create a file screen that does not allow files with an MP3 extension to be stored in personal shared folders on a file server.

Storage reports Storage reports are used to help you identify trends in disk usage and how your data is classified. You can also monitor a selected group of users for attempts to save unauthorized files.

6 Multi-Tenant SQL Server Service Management and Automation

Cloud computing is transforming the way service providers provide and consume services with the promise of more productive infrastructure and more predictable applications. System Center 2012 R2 delivers on this promise by helping your enterprise to benefit from private, hosted, and public cloud computing while still supporting your unique business needs. It helps to organize service providers’ assets—network, storage, and compute—into a hybrid cloud model spanning private cloud and public cloud services from a single console view. Infrastructure Management: System Center 2012 R2 provides a common management toolset to help you configure, provision, monitor, and operate service providers’ infrastructure. Service Delivery and Automation: System Center 2012 R2 helps you simplify and standardize your data center with flexible service delivery and automation. Using the Windows Azure Pack and Orchestrator components of System Center 2012, service providers can automate core organizational process workflows. You can also integrate and extend your existing toolsets and build flexible workflows (or runbooks) to automate processes across service providers IT assets and organizations. SQL Server Management: System Center 2012 R2 offers unique SQL Server management capabilities that can help you deliver agile, predictable application services. Using the Windows Azure Pack, Operations Manager, and Virtual Machine Manager components of System Center 2012 R2, service providers can provide SQL as a Service—where a “service” is a deployed instance of a cloud-style application along with its associated configuration and virtual infrastructure.

749

6.1 Operations Manager Microsoft has a long history of defining and refining monitoring capabilities for its products. System Center 2012 R2 Operations Manager continues this tradition as a solution with a deeper level of insight and improved scalability. With Operations Manager, your organization can gain levels of visibility into its infrastructure at every level of the stack, helping to ensure that the infrastructure is optimized and running efficiently. Fundamentally, Operations Manager provides infrastructure monitoring that is flexible and cost effective, better ensures the predictable performance and availability of vital applications, and offers comprehensive oversight of your data center and cloud—both private and public. Operations Manager helps IT administrators to monitor services, devices, and operations for many computers in a single console. Operations Manager includes numerous views that show state, health, and performance information, as well as alerts generated for availability, performance, configuration, and security situations.

6.1.1SQL Server 2014 Management Pack The ability to provide end-to-end management across infrastructure is a critical step in ensuring the health of the hosts and clusters, virtual machines, and private cloud itself. Further, Operations Manager can be used to monitor mission-critical SQL Server workloads using the SQL Server 2014 Management Pack. This management pack provides the capabilities for Operations Manager 2007 R2 and Operations Manager 2012 to discover SQL Server 2005, 2008, 2008 R2, SQL Server 2012 and SQL Server 2014. It monitors SQL Server components such as database engine instances, databases, and SQL Server agents. The SQL Server 2014 Management Pack monitors performance, availability, and configuration; performance data collection; and default thresholds. In addition to health monitoring capabilities, this management pack includes dashboard views, diagram views and extensive knowledge with embedded inline tasks, and views that help near real-time diagnosis and resolution of detected issues. Plus, you can integrate the monitoring of SQL Server components into your service-oriented monitoring scenarios. The SQL Server 2012 Management Pack provides the following key features:

SQL Version Support: Support for Enterprise, Standard, and Express editions of SQL Server 2005, 2008, 2008 R2, 2012, and 2014, as well as 32bit, 64bit, and ia64 architectures.

Simple and Complex Configuration Support: Clustered installations, multiple instances, and 32bit roles running on a 64bit operating system.

750

Discovery and Monitoring: SQL Server roles such as DB Engine, Reporting Services, Analysis Services, and Integrations Services, as well as SQL Server components such as databases, SQL Agent, and SQL jobs.

Core Monitoring: Database free space, SQL Server-related performance, SQL Server-related alerts, and lists of the various SQL Server roles and components that are discovered and their related states.

AlwaysOn Monitoring: Automatic discovery and monitoring of availability groups, availability replicas, and availability databases for hundreds of computers; health roll-up from availability database to availability replicas; and detailed knowledge with every critical health state to help faster resolution to a problem.

Policy-Based Management: Auto-discovery of custom PBM polices targeting AlwaysOn and database components; roll-up of the health of policy implementation within the management pack under extended health.

Mirroring and Replication Monitoring: Discovery of mirroring databases, witness, and mirroring group; monitoring of database mirror state, database mirror witness state, and mirroring partners’ state; custom diagram view to visually represent the primary and mirrored databases; approximately 20 rules to detect replication events.

By deploying Operations Manager with the SQL Server 2014 Management Pack, service provider administrators and database administrators can gain a deeper level of insight into their workloads, helping to optimize performance and remediate issues quickly. Continuing the DBA example, a DBA can access this information directly in the Operations Manager console using the My Workspace functionality. My Workspace provides a private area in the Operations Manager console that can be customized for the DBA’s specific needs. Using My Workspace, the DBA can create folders to organize the workspace, add shortcuts to favorite views, save useful searches, and create views that are only visible to self. Using the same Windows credentials, the DBA can log on to My Workspace from any Operations Manager console. In addition, the DBA can subscribe to alerts from Operations Manager to receive email notification of any issues that arise.

6.2 OrchestratorSystem Center 2012 R2 Orchestrator provides tools to build, test, debug, deploy, and manage automation in your environment. These automated procedures, called runbooks, can function independently or start other runbooks. The standard activities defined in every installation of Orchestrator provide a variety of monitors, tasks, and runbook controls, which you can integrate with a wide range of system processes. Each activity in a runbook publishes data that is available to any

751

subsequent activity in that runbook. You can use this published data to provide dynamic decision-making capabilities (like creating emails, alerts, log files, accounts, and more).

752

Service providers can use Orchestrator to improve efficiency and reduce operational costs to support cross-departmental objectives. Orchestrator provides an environment with shared access to common data. By using Orchestrator, you can evolve and automate key processes between groups and consolidate repetitive manual tasks. You can automate cross-functional team processes and enforce best practices for incident, change, and service management by creating runbooks that are customized for your requirements. Through automation, regularly recurring tasks reduce the number of manual and error-prone activities in your environment, helping to improve reliability and predictability. Orchestrator integrates with System Center, other Microsoft products, and non-Microsoft products to help interoperability across the data center. Orchestrator improves efficiency across multiple tools, systems, and departments by eliminating or crossing technology and organizational process structures. You can extend the capabilities of Orchestrator with integration packs that include additional functionality for both Microsoft and non-Microsoft products and technologies. Orchestrator activities and integration packs reduce unanticipated errors and shorten service delivery time by automating the common tasks associated with enterprise tools and products. Orchestration is the collective name for the automated arrangement, coordination, and management of systems, software, and practices. It helps the management of complex cross-domain processes. Orchestrator provides the tools for orchestration to combine software, hardware, and manual processes into a seamless system. These tools let you connect and automate workflows. Just as manufacturing companies have automated common and repeatable tasks from their production processes, you can adopt this same efficiency in the hosting environment by using Orchestrator to seamlessly perform and monitor your service delivery processes. Orchestrator can handle routine tasks, ensure process enforcement, and reliably meet the demands of the largest enterprises. Orchestrator interoperates with other System Center products to integrate IT administrative tasks from start to finish. If you have a custom in-house solution, Orchestrator provides extensible integration to any system through the Orchestrator Integration Toolkit. You can create custom integrations that allow Orchestrator to connect to any environment. Orchestrator uses a Representational State Transfer (REST)-based web service that can perform processes like start and stop runbook jobs and get reporting information in Open Data protocol (OData) format. The web service lets you develop applications that can use live data from Orchestrator.

6.3 Windows Azure Pack

753

On top of Windows Server and System Center, Windows Azure Pack (WAP) helps enterprises and service providers to deliver a subset of Microsoft Azure services on premise. Consistency with Azure is achieved at the API level and through the portal, both shipping as part of WAP.WAP provides several services out of the box, including Web Sites, VM Clouds and SQL Server, among others. All these services are surfaced into WAP through the corresponding “Resource Providers”.

The following two resource providers could be leveraged for delivering multi-tenant SQL as services:

The “VM Clouds” Resource Provider helps tenants to deploy and manage Virtual Machines, which could host SQL Server, on top of a Hyper-V fabric managed by the Virtual Machine Manager component of System Center. This could be used to deliver the Virtual machine based multi-tenancy model.

The “SQL Server” Resource Provider – helps tenants to deploy and manage Databases on top of a SQL Server fabric. This could be used for delivering the shared database multi-tenancy model described earlier.

Note: current version of SQL Server Resource Provider doesn’t provide any capabilities to manage SQL Server Resource Governor, and doesn’t provide any backup/restore features for tenants to backup/restore their databases. The SQL Server Resource Governor capability may be added to a version of SQL Server Resource Provider in the near future.

754

http://www.microsoft.com/en-us/server-cloud/products/windows-azure-pack/default.aspx

6.3.1Service Management AutomationService Management Automation is a set of tools that is integrated as the Automation extension in Windows Azure Pack for Windows Server. Service providers can use Automation to construct, run, and manage runbooks to integrate, orchestrate, and automate their business processes. Automation runbooks run on the Windows PowerShell workflow engine.Service Management Automation uses the following three underlying components that are connected to Windows Azure Pack through the Service Management Automation service endpoint:Web service

Connects to Windows Azure Pack Distributes runbook jobs to runbook workers Supports HTTPS Enables security group to control access

Runbook worker Executes runbook jobs Runs under a service account

PowerShell module Enables Automation management by using Windows PowerShell cmdlets

Service providers could also leverage the Service Management Automation to further customize and extend their multi-tenant SQL offerings.Note: A set of Service Management Automation runbooks will be provided as samples along with this reference architecture document.

755

service provider reference architecture - database...

Documents