Skip to content

Latest commit

 

History

History
113 lines (75 loc) · 9.32 KB

File metadata and controls

113 lines (75 loc) · 9.32 KB
Error in user YAML: (<unknown>): mapping values are not allowed in this context at line 3 column 9
---
title: 'TDE for Azure SQL Database and Data Warehouse | Microsoft Docs'
description: An overview of Transparent Data Encryption for SQL Database and Data Warehouse. The document covers its benefits, and the options for configuration, including Service-managed TDE and Bring Your Own Key.
keywords:
services: sql-database
documentationcenter: ''
author: becczhang
manager: jhubbard
editor: ''

ms.assetid: 
ms.service: sql-database
ms.custom: security
ms.workload:
ms.tgt_pltfrm:
ms.devlang: na
ms.topic: article
ms.date: 06/20/2017
ms.author: rebeccaz

--- 

Transparent Data Encryption for Azure SQL Database and Data Warehouse

Transparent Data Encryption (TDE) helps protect Azure SQL Database and Data Warehouse against the threat of malicious activity by performing real-time encryption and decryption of the database, associated backups, and transaction log files at rest without requiring changes to the application.

TDE encrypts the storage of an entire database by using a symmetric key called the database encryption key (DEK). This database encryption key is protected by the TDE protector, which is either a service-managed certificate (“Service-Managed TDE”) or an asymmetric key stored in Azure Key Vault (“Bring Your Own Key”). The TDE protector is set at the server level.

On database startup, the encrypted DEK is decrypted, and then used for decryption and re-encryption of the database files in the SQL Engine process. TDE performs real-time I/O encryption and decryption of the data at the page level. Each page is decrypted when read into memory, and encrypted before being written to disk. For a general description of TDE, see Transparent Data Encryption (TDE).

SQL Server running on an Azure virtual machine can also use an asymmetric key from Key Vault. The configuration steps are different from using an asymmetric key in Azure SQL Database. For more information, see Extensible Key Management Using Azure Key Vault (SQL Server).

Service-Managed TDE

In Azure, the default setting for TDE is that the database encryption key is protected by a built-in server certificate. The built-in server certificate is unique for each server. If a database is in a geo-replication relationship, both the primary and geo-secondary database will be protected by the primary’s parent server key. If 2 databases are connected to the same server, they share the same built-in certificate. Microsoft automatically rotates these certificates at least every 90 days.

Microsoft also seamlessly moves and manages the keys as needed for Geo-replication and restores.

Bring Your Own Key

Bring Your Own Key (BYOK) support allows the user to take control over their TDE encryption keys and control who can access them and when. Azure Key Vault (AKV), which is Azure’s cloud-based external key management system, is the first key management service that TDE has integrated with for BYOK support. With BYOK, the database encryption key is protected by an asymmetric key stored in AKV. The asymmetric key never leaves Key Vault; once the server has permissions to a key vault, the server sends basic key operation requests to it through the Key Vault service. The asymmetric key is set at the server level and inherited by all databases under that server. With BYOK support, users can now control key management tasks including key rotations, key vault permissions, deleting keys, and enable auditing/reporting on all encryption keys. Key Vault provides central key management, leverages tightly monitored hardware security modules (HSMs), and promotes separation of management of keys and data to help meet regulatory compliances. To learn more about Key Vault, visit the Key Vault documentation page.

To learn more about TDE with BYOK support for Azure SQL Database and Data Warehouse, see Transparent Data Encryption with Bring Your Own Key support.

To start using TDE with BYOK support, visit the how-to guide Turn on Transparent Data Encryption using your own key from Key Vault Using PowerShell.

Moving a TDE protected database

You do not need to decrypt databases for operations within Azure. The TDE settings on the source database or primary database are transparently inherited on the target. This includes operations involving:

  • Geo-Restore
  • Self-Service Point in Time Restore
  • Restore a Deleted Database
  • Active Geo_Replication
  • Creating a Database Copy

When exporting a TDE protected database, the exported content of the database is not encrypted. This exported content is stored in unencrypted .bacpac files. Be sure to protect the .bacpac files appropriately and enable TDE once import of the new database is completed.

For example, if the .bacpac file is exported from an on-premises SQL Server, then the imported content of the new database is not automatically encrypted. Likewise, if the .bacpac file is exported to an on-premises SQL Server, the new database is also not automatically encrypted.

The one exception is when exporting to and from Azure SQL Database – TDE is enabled in the new database, but the .bacpac file itself is still not encrypted.

Managing Transparent Data Encryption in Azure Portal

To configure TDE through Azure Portal, you must be connected as the Azure Owner, Contributor, or SQL Security Manager.

Transparent Data Encryption is set on the database level. To enable TDE on a database, visit the Azure Portal and sign in with your Azure Administrator or Contributor account. Find the TDE settings under your user database. By default, service-managed TDE is used, and a TDE certificate is automatically generated for the server containing the database.

service managed TDE 

The TDE master key, also referred to as the TDE Protector, is set on the server level. To use TDE with Bring Your Own Key support and protect your databases with a key from Azure Key Vault, visit the TDE settings under your server.

TDE with BYOK support 

Programmatically managing Transparent Data Encryption in Azure SQL Database and Data Warehouse

PowerShell

To configure TDE through PowerShell, you must be connected as the Azure Owner, Contributor, or SQL Security Manager.

Cmdlet Description
Set-AzureRmSqlDatabaseTransparentDataEncryption Enables or disables TDE for a database.
Get-​Azure​Rm​Sql​Database​Transparent​Data​Encryption Gets the TDE state for a database.
Get-​Azure​Rm​Sql​Database​Transparent​Data​Encryption​Activity Checks the encryption progress for a database.
Add-AzureRmSqlServerKeyVaultKey Adds a Key Vault key to a SQL server.
Get-AzureRmSqlServerKeyVaultKey Gets a SQL server's Key Vault keys.
Set-AzureRmSqlServerTransparentDataEncryptionProtector Sets the TDE Protector for a SQL server.
Get-AzureRmSqlServerTransparentDataEncryptionProtector Gets the Transparent Data Encryption (TDE) protector.
Remove-AzureRmSqlServerKeyVaultKey Removes a Key Vault key from a SQL server.

Transact-SQL

Connect to the database using a login that is an administrator or member of the dbmanager role in the master database.

Command Description
ALTER DATABASE (Azure SQL Database) Use SET ENCRYPTION ON/OFF to encrypt or decrypt a database.
sys.dm_database_encryption_keys Returns information about the encryption state of a database and its associated database encryption keys.

The TDE Protector cannot be switched to a key from Azure Key Vault using T-SQL. Please use PowerShell or the Azure Portal.

Next steps