Plan for Host Guardian Service attestation
Applies to: SQL Server 2019 (15.x) - Windows only
When you use Always Encrypted with secure enclaves, make sure that the client application is talking to a trustworthy enclave within the SQL Server process. For a virtualization-based security (VBS) enclave, this requirement includes verifying both the code inside the enclave is valid and the computer hosting SQL Server is trustworthy. Remote attestation achieves this goal by introducing a third party that can validate the identity (and optionally, the configuration) of the SQL Server computer. Before SQL Server can use an enclave to run a query, it must provide information to the attestation service about its operating environment to obtain a health certificate. This health certificate is then sent to the client, which can independently verify its authenticity with the attestation service. Once the client trusts the health certificate, it knows it is talking to a trustworthy VBS enclave and will issue the query that will use that enclave.
The Host Guardian Service (HGS) role in Windows Server 2019 provides remote attestation capabilities for Always Encrypted with VBS enclaves. This article will guide you through the pre-deployment decisions and requirements to use Always Encrypted with VBS enclaves and HGS attestation.
The Host Guardian Service (HGS) is a clustered web service that runs on Windows Server 2019. In a typical deployment, there will be 1-3 HGS servers, at least one computer running SQL Server, and a computer running a client application or tools, such as SQL Server Management Studio. Since the HGS is responsible for determining which computers running SQL Server are trustworthy, it requires both physical and logical isolation from the SQL Server instance it is protecting. If the same admins have access to HGS and a SQL Server computer, they could configure the attestation service to allow a malicious computer to run SQL Server, enabling them to compromise the VBS enclave.
HGS setup will automatically create a new Active Directory domain for the HGS servers, failover cluster resources, and administrator accounts.
The computer running SQL Server doesn't need to be in a domain, but if it is, it should be a different domain than the one the HGS server uses.
The HGS feature automatically installs and configures a failover cluster. In a production environment, it's recommended to use three HGS servers for high availability. Refer to the failover cluster documentation for details on how cluster quorum is determined and alternative configurations, including two node clusters with an external witness.
Shared storage is not required between the HGS nodes. A copy of the attestation database is stored on each HGS server and is automatically replicated over the network by the cluster service.
Both the SQL client and SQL Server need to be able to communicate with HGS over HTTP. Configure HGS with a TLS certificate to encrypt all communications between the SQL Client and HGS, as well as between SQL Server and HGS. This configuration helps protect from man-in-the-middle attacks and ensures you're talking to the correct HGS server.
HGS servers require connectivity between each node in the cluster to ensure the attestation service database stays in sync. It's a failover cluster best practice to connect the HGS nodes on one network for cluster communication and use a separate network for other clients to communicate with HGS.
When a computer running SQL Server tries to attest with HGS, it will first ask HGS how it should attest. HGS supports two attestation modes for use with SQL Server:
|TPM||Trusted Platform Module (TPM) attestation provides the strongest assurance about the identity and integrity of the computer attesting with HGS. It requires the computers running SQL Server to have TPM version 2.0 installed. Each TPM chip contains a unique and immutable identity (Endorsement Key) that can be used to identify a particular computer. TPMs also measure the boot process of the computer, storing hashes of security-sensitive measurements in Platform Control Registers (PCRs) that can be read, but not modified by the operating system. These measurements are used during attestation to provide cryptographic proof that a computer is in the security configuration it claims to be.|
|Host Key||Host key attestation is a simpler form of attestation that only verifies the identity of a computer by using an asymmetric key pair. The private key is stored on the computer running SQL Server and the public key is provided to HGS. The security configuration of the computer is not measured and a TPM 2.0 chip is not required on the computer running SQL Server. It is important to protect the private key installed on the SQL Server computer because anyone who obtains this key can impersonate a legitimate SQL Server computer and the VBS enclave running inside SQL Server.|
In general, we make the following recommendations:
- For physical production servers, we recommend using TPM attestation for the additional assurances it provides.
- For virtual production servers, we recommend host key attestation since most virtual machines do not have virtual TPMs or Secure Boot. If you're using a security-enhanced VM like an on-premises shielded VM, you may choose to use TPM mode. In all virtualized deployments, the attestation process only analyzes your VM environment -- not the virtualization platform underneath the VM.
- For dev/test scenarios, we recommend host key attestation because it is easier to set up.
In the VBS enclave trust model, the encrypted queries and data are evaluated in a software-based enclave to protect it from the host OS. Access to this enclave is protected by the hypervisor in the same way two virtual machines running on the same computer can't access each other's memory. In order for a client to trust that it's talking to a legitimate instance of VBS, you must use TPM-based attestation that establishes a hardware root of trust on the SQL Server computer. The TPM measurements captured during the boot process include the unique identity key of the VBS instance, ensuring the health certificate is only valid on that exact computer. Further, when a TPM is available on a computer running VBS, the private part of the VBS identity key is protected by the TPM, preventing anyone from trying to impersonate that VBS instance.
Secure Boot is required with TPM attestation to ensure UEFI loaded a legitimate, Microsoft-signed bootloader and that no rootkits intercepted the hypervisor boot process. Additionally, an IOMMU device is required by default to ensure any hardware devices with direct memory access can't inspect or modify enclave memory.
These protections all assume the computer running SQL Server is a physical machine. If you virtualize the computer running SQL Server, you can no longer guarantee that the memory of the VM is safe from inspection by the hypervisor or hypervisor admin. A hypervisor admin could, for example, dump the memory of the VM and gain access to the plaintext version of the query and data in the enclave. Similarly, even if the VM has a virtual TPM, it can only measure the state and integrity of the VM operating system and boot environment. It cannot measure the state of the hypervisor controlling the VM.
However, even when SQL Server is virtualized, the enclave is still protected from attacks originating within the VM operating system. If you trust your hypervisor or cloud provider, and are primarily worried about database admin and OS admin attacks on sensitive data, a virtualized SQL Server may meet your requirements.
Similarly, Host Key attestation is still valuable in situations where a TPM 2.0 module isn't installed on the computer running SQL Server or in dev/test scenarios where security isn't paramount. You can still use many of the security features mentioned above, including Secure Boot and a TPM 1.2 module, to better protect VBS and the operating system as a whole. But, since there's no way for HGS to verify the computer actually has these settings enabled with Host Key attestation, the client isn't assured the host is indeed using all available protections.
HGS server prerequisites
The computer(s) running the Host Guardian Service role should meet the following requirements:
|Operating System||Windows Server 2019 Standard or Datacenter edition|
|CPU||2 cores (min), 4 cores (recommended)|
|RAM||8 GB (min)|
|NICs||2 NICs with static IPs recommended (1 for cluster traffic, 1 for HGS service)|
HGS is a CPU-bound role because of the number of actions that require encryption and decryption. Using modern processors with cryptographic acceleration capabilities will improve HGS performance. Storage requirements for attestation data are minimal, on the range of 10 KB to 1 MB per unique computer attesting.
Do not join the HGS computer(s) to a domain before you start.
SQL Server computer prerequisites
These requirements include:
- SQL Server 2019 (15.x) or later
- Windows 10 Enterprise version 1809 or later; or Windows Server 2019 Datacenter edition. Other editions of Windows 10 and Windows Server don't support attestation with HGS.
- CPU support for virtualization technologies:
- Intel VT-x with Extended Page Tables.
- AMD-V with Rapid Virtualization Indexing.
- If you're running SQL Server in a VM, the hypervisor and physical CPU must offer nested virtualization capabilities. See the trust model section for information on the assurances when running VBS enclaves in a VM.
- On Hyper-V 2016 or later, enable nested virtualization extensions on the VM processor.
- In Azure, select a VM size that supports nested virtualization. All v3 series VMs support nested virtualization, for example Dv3 and Ev3. See Create a nesting capable Azure VM.
- On VMware vSphere 6.7 or later, enable virtualization-based security support for the VM as described in the VMware documentation.
- Other hypervisors and public clouds may support nested virtualization capabilities that enable Always Encrypted with VBS Enclaves as well. Check your virtualization solution's documentation for compatibility and configuration instructions.
- If you plan to use TPM attestation, you'll need a TPM 2.0 rev 1.16 chip ready for use in the server. At this time, HGS attestation doesn't work with TPM 2.0 rev 1.38 chips. Additionally, the TPM must have a valid Endorsement Key Certificate.
Roles and responsibilities when configuring attestation with HGS
Setting up attestation with HGS involves configuring components of different types: HGS, SQL Server computers, SQL Server instances, and applications that trigger enclave attestation. Configuring components of each type is performed by users assuming one of the below distinct roles:
- HGS administrator - deploys HGS, registers SQL Server computers with HGS, and shares the HGS attestation URL with SQL Server computer administrators and client application administrators.
- SQL Server computer administrator - installs attestation client components, enables VBS on SQL Server computers, provides the HGS administrator with the information required to register the SQL Server computers with HGS, configures the attestation URL on SQL Server computers, and verifies SQL Server computers can successfully attest with HGS.
- DBA - configures secure enclaves in SQL Server instances.
- Application administrator - configures application with the attestation URL obtained from the HGS administrator.
In production environments (handling real sensitive data), it is important your organization adheres to role separation when configuring attestation, where each distinct role is assumed by different people. In particular, if the goal of deploying Always Encrypted in your organization is to reduce the attack surface area by ensuring SQL Server computer administrators and DBAs cannot access sensitive data, SQL Server administrators and DBAs should not control the HGS servers.
Dev/test environment considerations
If you're using Always Encrypted with VBS enclaves in a development or test environment and don't require high availability or strong protection of the computer running SQL Server, you can make any or all of the following concessions for a simplified deployment:
- Deploy only one node of HGS. Even though HGS installs a failover cluster, you don't need to add additional nodes if high availability isn't a concern.
- Use host key mode instead of TPM mode for a simpler setup experience.
- Virtualize HGS and/or the SQL Server to save physical resources.
- Run SSMS or other tools for configuring Always Encrypted with secure enclaves on the same computer as SQL Server. This leaves the column master keys on the same computer as SQL Server, so don't do this in a production environment.