Events
Mar 31, 11 PM - Apr 2, 11 PM
The biggest SQL, Fabric and Power BI learning event. March 31 – April 2. Use code FABINSIDER to save $400.
Register todayThis browser is no longer supported.
Upgrade to Microsoft Edge to take advantage of the latest features, security updates, and technical support.
Applies to:
SQL Server 2019 (15.x) and later - Windows only
Azure SQL Database
Always Encrypted with secure enclaves expands confidential computing capabilities of Always Encrypted by enabling in-place encryption and richer confidential queries. Always Encrypted with secure enclaves is available in SQL Server 2019 (15.x) and later, as well as in Azure SQL Database.
Introduced in Azure SQL Database in 2015 and in SQL Server 2016 (13.x), Always Encrypted protects the confidentiality of sensitive data from malware and high-privileged unauthorized users: Database Administrators (DBAs), computer admins, cloud admins, or anyone else who has legitimate access to server instances, hardware, etc., but shouldn't have access to some or all of the actual data.
Without the enhancements discussed in this article, Always Encrypted protects the data by encrypting it on the client side and never allowing the data or the corresponding cryptographic keys to appear in plaintext inside the Database Engine. As a result, the functionality on encrypted columns inside the database is severely restricted. The only operations the Database Engine can perform on encrypted data are equality comparisons (only available with deterministic encryption). All other operations, including cryptographic operations (initial data encryption or key rotation) and richer queries (for example, pattern matching) aren't supported inside the database. Users need to move their data outside of the database to perform these operations on the client-side.
Always Encrypted with secure enclaves addresses these limitations by allowing some computations on plaintext data inside a secure enclave on the server side. A secure enclave is a protected region of memory within the Database Engine process. The secure enclave appears as an opaque box to the rest of the Database Engine and other processes on the hosting machine. There's no way to view any data or code inside the enclave from the outside, even with a debugger. These properties make the secure enclave a trusted execution environment that can safely access cryptographic keys and sensitive data in plaintext, without compromising data confidentiality.
Always Encrypted uses secure enclaves as illustrated in the following diagram:
When parsing a Transact-SQL statement submitted by an application, the Database Engine determines if the statement contains any operations on encrypted data that require the use of the secure enclave. For such statements:
The client driver sends the column encryption keys required for the operations to the secure enclave (over a secure channel), and submits the statement for execution.
When processing the statement, the Database Engine delegates cryptographic operations or computations on encrypted columns to the secure enclave. If needed, the enclave decrypts the data and performs computations on plaintext.
During statement processing, both the data and the column encryption keys aren't exposed in plaintext in the Database Engine outside of the secure enclave.
To use Always Encrypted with secure enclaves, an application must use a client driver that supports the feature. Configure the application and the client driver to enable enclave computations and enclave attestation (see the Secure enclave attestation section below). For details, including the list of supported client drivers, see Develop applications using Always Encrypted.
Always Encrypted supports the following enclave technologies (or enclave types):
The type of the enclave available for your database depends on the SQL product hosting it (Azure SQL Database vs. SQL Server) and (in the case of Azure SQL Database) the configuration of your database.
In SQL Server 2019 (15.x) and later, Always Encrypted supports VBS enclaves. (Intel SGX enclaves aren't supported.)
In Azure SQL Database, a database can use either an Intel SGX enclave or a VBS enclave, depending on the hardware the database is configured to run on:
Note
VBS enclaves are currently available in all Azure SQL Database regions except: Jio India Central.
See the Security considerations section for important information on the level protection each enclave type provides.
Enclave attestation is a defense-in-depth mechanism that can help detect attacks that involve tampering with the enclave code or its environment by malicious administrators.
Enclave attestation allows a client application to establish trust with the secure enclave for the database, the application is connected to, before the app uses the enclave for processing sensitive data. The attestation workflow verifies the enclave is a genuine VBS or Intel SGX enclave and the code running inside it is the genuine Microsoft-signed enclave library for Always Encrypted. During attestation, both the client driver within the application and the Database Engine communicate with an external attestation service using a client-specified endpoint.
Always Encrypted can use one of the two attestation services:
To enable Always Encrypted with secure enclaves for your application, you need to set an attestation protocol in the configuration of the client driver in your application. An attestation protocol value determines whether 1) the client app will use attestation, and, if so, 2) it specifies the type of the attestation service to it will use. The below table captures the supported attestation protocols for the valid SQL product and enclave type combinations:
Hosting product | Enclave type | Supported attestation protocols |
---|---|---|
SQL Server 2019 (15.x) and later | VBS enclaves | HGS, No attestation |
Azure SQL Database | SGX enclaves (DC-series databases) | Microsoft Azure Attestation |
Azure SQL Database | VBS enclaves | No attestation |
A few important points to call out:
For more information, see:
Always Encrypted with secure enclaves introduces the concept of enclave-enabled keys:
master
key that has the ENCLAVE_COMPUTATIONS
property specified in the column master
key metadata object inside the database. The column master
key metadata object must also contain a valid signature of the metadata properties. For more information, see CREATE COLUMN MASTER KEY (Transact-SQL)master
key. Only enclave-enabled column encryption keys can be used for computations inside the secure enclave.For more information, see Manage keys for Always Encrypted with secure enclaves.
An enclave-enabled column is a database column encrypted with an enclave-enabled column encryption key.
The two key benefits of Always Encrypted with secure enclaves are in-place encryption and rich confidential queries.
In-place encryption allows cryptographic operations on database columns inside the secure enclave, without moving the data outside of the database. In-place encryption improves the performance and the reliability of cryptographic operations. You can perform in-place encryption using the ALTER TABLE (Transact-SQL) statement.
The cryptographic operations supported in-place are:
In-place encryption is allowed with both deterministic and randomized encryption, as long as the column encryption keys involved in a cryptographic operation are enclave-enabled.
Note
SQL Server 2022 (16.x) adds additional support for confidential queries with JOIN, GROUP BY and ORDER BY operations on encrypted columns.
Confidential queries are DML queries that involve operations on enclave-enabled columns performed inside the secure enclave.
The operations supported inside the secure enclaves are:
Operation | Azure SQL Database | SQL Server 2022 (16.x) | SQL Server 2019 (15.x) |
---|---|---|---|
Comparison Operators | Supported | Supported | Supported |
BETWEEN (Transact-SQL) | Supported | Supported | Supported |
IN (Transact-SQL) | Supported | Supported | Supported |
LIKE (Transact-SQL) | Supported | Supported | Supported |
DISTINCT | Supported | Supported | Supported |
Joins | Supported | Supported | Only nested loop joins supported |
SELECT - ORDER BY Clause (Transact-SQL) | Supported | Supported | Not supported |
SELECT - GROUP BY- Transact-SQL | Supported | Supported | Not supported |
Note
The above operations inside secure enclaves require randomized encryption. Deterministic encryption is not supported. Equality comparison remains the operation available for columns using deterministic encryption.
The compatibility level of the database should be set to SQL Server 2022 (160) or higher.
In Azure SQL Database and in SQL Server 2022 (16.x), confidential queries using enclaves on a character string column (char
, nchar
) require the column uses a binary-code point (_BIN2) collation or a UTF-8 collation. In SQL Server 2019 (15.x), a_BIN2 collation is required.
For more information, see Run Transact-SQL statements using secure enclaves.
You can create nonclustered indexes on enclave-enabled columns using randomized encryption to make confidential DML queries using the secure enclave run faster.
To ensure an index on a column that is encrypted using randomized encryption doesn't leak sensitive data, the key values in the index data structure (B-tree) are encrypted and sorted based on their plaintext values. Sorting by the plaintext value is also useful for processing queries inside the enclave. When the query executor in the Database Engine uses an index on an encrypted column for computations inside the enclave, it searches the index to look up specific values stored in the column. Each search might involve multiple comparisons. The query executor delegates each comparison to the enclave, which decrypts a value stored in the column and the encrypted index key value to be compared, it performs the comparison on plaintext and it returns the result of the comparison to the executor.
Creating indexes on columns that use randomized encryption and aren't enclave-enabled remains unsupported.
An index on a column using deterministic encryption is sorted based on ciphertext (not plaintext), regardless if the column is enclave-enabled or not.
For more information, see Create and use indexes on columns using Always Encrypted with secure enclaves. For general information on how indexing in Database Engine works, see the article, Clustered and Nonclustered Indexes Described.
If an instance of SQL Server fails, its databases might be left in a state where the data files might contain some modifications from incomplete transactions. When the instance is started, it runs a process called database recovery, which involves rolling back every incomplete transaction found in the transaction log to make sure the integrity of the database is preserved. If an incomplete transaction made any changes to an index, those changes also need to be undone. For example, some key values in the index might need to be removed or reinserted.
Important
Microsoft strongly recommends enabling Accelerated database recovery (ADR) for your database, before creating the first index on an enclave-enabled column encrypted with randomized encryption. ADR is enabled by default in Azure SQL Database and Azure SQL Managed Instance. ADR is available but not enabled by default in SQL Server 2019 (15.x) and later.
With the traditional database recovery process (that follows the ARIES recovery model), to undo a change to an index, the Database Engine needs to wait until an application provides the column encryption key for the column to the enclave, which can take a long time. Accelerated database recovery (ADR) dramatically reduces the number of undo operations that must be deferred because a column encryption key isn't available in the cache inside the enclave. Consequently, it substantially increases database availability by minimizing a chance for a new transaction to get blocked. With ADR enabled, the Database Engine might still need a column encryption key to complete cleaning up old data versions but it does that as a background task that doesn't impact the availability of the database or user transactions. You might see error messages in the error log, indicating failed cleanup operations due to a missing column encryption key.
The following security considerations apply to Always Encrypted with secure enclaves.
master
keys or column encryption keys with the DBAs. A DBA can manage indexes on encrypted columns without having direct access to the keys by using the cache of column encryption keys inside the enclave.When configuring a high availability or disaster recovery solution for a database using Always Encrypted with secure enclaves, make sure that all database replicas can use a secure enclave. If an enclave is available for the primary replica, but not for the secondary replica, any statement that attempts to use the functionality of Always Encrypted with secure enclaves will fail after the failover.
When you copy or migrate a database using Always Encrypted with secure enclaves, make sure the target environment always supports enclaves. Otherwise, statements that use enclaves won't work on the copy or the migrated database.
Here are the specific considerations you should keep in mind:
SQL Server
Azure SQL Database
In both SQL Server and Azure SQL Database, when you migrate your database using a bacpac file, you need to make sure you drop all indexes for enclave-enabled columns using randomized encryption before creating the bacpac file.
Always Encrypted with secure enclaves addresses some limitations of Always Encrypted by supporting in-place encryption and richer confidential queries with indexes, as explained in Confidential computing capabilities for enclave-enabled columns.
All other limitations for Always Encrypted listed in Limitations also apply to Always Encrypted with secure enclaves.
The following limitations are specific to Always Encrypted with secure enclaves:
ALTER TABLE
/ALTER COLUMN
Transact-SQL statement. Use two separate statements.nchar[n]
and nvarchar[n]
, if n is greater than 3967.char[n]
, varchar[n]
, binary[n]
, varbinary[n]
, if n is greater than 7935.master
keys are Windows Certificate Store and Azure Key Vault.ALTER TABLE
/ALTER COLUMN
, you need to issue the statement using a query window in SSMS or Azure Data Studio, or you can write your own program that issues the statement. Currently, the Set-SqlColumnEncryption
cmdlet in the SqlServer PowerShell module and the Always Encrypted wizard in SQL Server Management Studio don't support in-place encryption. Move the data out of the database for cryptographic operations, even if the column encryption keys used for the operations are enclave-enabled.Events
Mar 31, 11 PM - Apr 2, 11 PM
The biggest SQL, Fabric and Power BI learning event. March 31 – April 2. Use code FABINSIDER to save $400.
Register todayTraining
Certification
Microsoft Certified: Azure Database Administrator Associate - Certifications
Administer an SQL Server database infrastructure for cloud, on-premises and hybrid relational databases using the Microsoft PaaS relational database offerings.