You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
Copy file name to clipboardExpand all lines: articles/azure-sql/database/transparent-data-encryption-byok-overview.md
+15-15Lines changed: 15 additions & 15 deletions
Display the source diff
Display the rich diff
Original file line number
Diff line number
Diff line change
@@ -8,8 +8,8 @@ ms.subservice: security
8
8
ms.custom: seo-lt-2019, azure-synapse
9
9
ms.devlang:
10
10
ms.topic: conceptual
11
-
author: jaszymas
12
-
ms.author: jaszymas
11
+
author: shohamMSFT
12
+
ms.author: shohamd
13
13
ms.reviewer: vanto
14
14
ms.date: 02/01/2021
15
15
---
@@ -81,13 +81,13 @@ Auditors can use Azure Monitor to review key vault AuditEvent logs, if logging i
81
81
82
82
### Requirements for configuring TDE protector
83
83
84
-
- TDE protector can be only asymmetric, RSA or RSA HSM key. The supported key lengths are 2048 and 3072 bytes.
84
+
- TDE protector can be only asymmetric, RSA or RSA HSM key. The supported key lengths are 2048 bytes and 3072 bytes.
85
85
86
86
- The key activation date (if set) must be a date and time in the past. Expiration date (if set) must be a future date and time.
87
87
88
88
- The key must be in the *Enabled* state.
89
89
90
-
- If you are importing existing key into the key vault, make sure to provide it in the supported file formats (.pfx, .byok, or .backup).
90
+
- If you are importing existing key into the key vault, make sure to provide it in the supported file formats (`.pfx`, `.byok`, or `.backup`).
91
91
92
92
> [!NOTE]
93
93
> Azure SQL now supports using a RSA key stored in a Managed HSM as TDE Protector. This feature is in **public preview**.
@@ -112,7 +112,7 @@ Azure Key Vault Managed HSM is a fully managed, highly available, single-tenant,
112
112
113
113
- If the key is generated in the key vault, create a key backup before using the key in AKV for the first time. Backup can be restored to an Azure Key Vault only. Learn more about the [Backup-AzKeyVaultKey](/powershell/module/az.keyvault/backup-azkeyvaultkey) command.
114
114
115
-
- Create a new backup whenever any changes are made to the key (e.g. key attributes, tags, ACLs).
115
+
- Create a new backup whenever any changes are made to the key (for example, key attributes, tags, ACLs).
116
116
117
117
-**Keep previous versions** of the key in the key vault when rotating keys, so older database backups can be restored. When the TDE protector is changed for a database, old backups of the database **are not updated** to use the latest TDE protector. At restore time, each backup needs the TDE protector it was encrypted with at creation time. Key rotations can be performed following the instructions at [Rotate the Transparent Data Encryption Protector Using PowerShell](transparent-data-encryption-byok-key-rotation.md).
118
118
@@ -127,13 +127,13 @@ When transparent data encryption is configured to use a customer-managed key, co
127
127
> [!NOTE]
128
128
> If the database is inaccessible due to an intermittent networking outage, there is no action required and the databases will come back online automatically.
129
129
130
-
After access to the key is restored, taking database back online requires additional time and steps, which may vary based on the time elapsed without access to the key and the size of the data in the database:
130
+
After access to the key is restored, taking database back online requires extra time and steps, which may vary based on the time elapsed without access to the key and the size of the data in the database:
131
131
132
-
- If key access is restored within 8 hours, the database will auto-heal within next hour.
132
+
- If key access is restored within 8 hours, the database will autoheal within next hour.
133
133
134
-
- If key access is restored after more than 8 hours, auto-heal is not possible and bringing the database back requires additional steps on the portal and can take a significant amount of time depending on the size of the database. Once the database is back online, previously configured server-level settings such as [failover group](auto-failover-group-overview.md) configuration, point-in-time-restore history, and tags **will be lost**. Therefore, it's recommended implementing a notification system that allows you to identify and address the underlying key access issues within 8 hours.
134
+
- If key access is restored after more than 8 hours, autoheal is not possible and bringing back the database requires extra steps on the portal and can take a significant amount of time depending on the size of the database. Once the database is back online, previously configured server-level settings such as [failover group](auto-failover-group-overview.md) configuration, point-in-time-restore history, and tags **will be lost**. Therefore, it's recommended implementing a notification system that allows you to identify and address the underlying key access issues within 8 hours.
135
135
136
-
Below is a view of the additional steps required on the portal to bring an inaccessible database back online.
136
+
Below is a view of the extra steps required on the portal to bring an inaccessible database back online.
@@ -160,7 +160,7 @@ To monitor database state and to enable alerting for loss of TDE protector acces
160
160
161
161
-[Azure Resource Health](../../service-health/resource-health-overview.md). An inaccessible database that has lost access to the TDE protector will show as "Unavailable" after the first connection to the database has been denied.
162
162
-[Activity Log](../../service-health/alerts-activity-log-service-notifications-portal.md) when access to the TDE protector in the customer-managed key vault fails, entries are added to the activity log. Creating alerts for these events will enable you to reinstate access as soon as possible.
163
-
-[Action Groups](../../azure-monitor/alerts/action-groups.md) can be defined to send you notifications and alerts based on your preferences, e.g. Email/SMS/Push/Voice, Logic App, Webhook, ITSM, or Automation Runbook.
163
+
-[Action Groups](../../azure-monitor/alerts/action-groups.md) can be defined to send you notifications and alerts based on your preferences, for example, Email/SMS/Push/Voice, Logic App, Webhook, ITSM, or Automation Runbook.
164
164
165
165
## Database backup and restore with customer-managed TDE
166
166
@@ -172,7 +172,7 @@ To restore a backup encrypted with a TDE protector from Key Vault, make sure tha
172
172
> At any moment there can be not more than one TDE protector set for a server. It's the key marked with "Make the key the default TDE protector" in the Azure portal blade. However, multiple additional keys can be linked to a server without marking them as a TDE protector. These keys are not used for protecting DEK, but can be used during restore from a backup, if backup file is encrypted with the key with the corresponding thumbprint.
173
173
174
174
If the key that is needed for restoring a backup is no longer available to the target server, the following error message is returned on the restore try:
175
-
"Target server `<Servername>` does not have access to all AKV URIs created between \<Timestamp #1> and \<Timestamp #2>. Please retry operation after restoring all AKV URIs."
175
+
"Target server `<Servername>` does not have access to all AKV URIs created between \<Timestamp #1> and \<Timestamp #2>. Retry operation after restoring all AKV URIs."
176
176
177
177
To mitigate it, run the [Get-AzSqlServerKeyVaultKey](/powershell/module/az.sql/get-azsqlserverkeyvaultkey) cmdlet for the target server or [Get-AzSqlInstanceKeyVaultKey](/powershell/module/az.sql/get-azsqlinstancekeyvaultkey) for the target managed instance to return the list of available keys and identify the missing ones. To ensure all backups can be restored, make sure the target server for the restore has access to all of keys needed. These keys don't need to be marked as TDE protector.
178
178
@@ -182,15 +182,15 @@ Additional consideration for log files: Backed up log files remain encrypted wit
182
182
183
183
## High availability with customer-managed TDE
184
184
185
-
Even in cases when there is no configured geo-redundancy for server, it is highly recommended to configure the server to use two different key vaults in two different regions with the same key material. The key in the secondary key vault in the other region should not be marked as TDE protector, and it's not even allowed. If there is an outage affecting the primary key vault, and only then, the system will automatically switch to the other linked key with the same thumbprint in the secondary key vault, if it exists. Note though that switch will not happen if TDE protector is inaccessible because of revoked access rights, or because key or key vault is deleted, as it may indicate that customer intentionally wanted to restrict server from accessing the key.Providing the same key material to two key vaults in different regions can be done by creating the key outside of the key vault, and importing them into both key vaults.
185
+
Even in cases when there is no configured geo-redundancy for server, it is highly recommended to configure the server to use two different key vaults in two different regions with the same key material. The key in the secondary key vault in the other region should not be marked as TDE protector, and it's not even allowed. If there is an outage affecting the primary key vault, and only then, the system will automatically switch to the other linked key with the same thumbprint in the secondary key vault, if it exists. Note though that switch will not happen if TDE protector is inaccessible because of revoked access rights, or because key or key vault is deleted, as it may indicate that customer intentionally wanted to restrict server from accessing the key.Providing the same key material to two key vaults in different regions can be done by creating the key outside of the key vault, and importing them into both key vaults.
186
186
187
-
Alternatively, it can be accomplished by generating key using the primary key vault co-located in the same region as the server and cloning the key into a key vault in a different Azure region. Use the [Backup-AzKeyVaultKey](/powershell/module/az.keyvault/Backup-AzKeyVaultKey) cmdlet to retrieve the key in encrypted format from the primary key vault and then use the [Restore-AzKeyVaultKey](/powershell/module/az.keyvault/restore-azkeyvaultkey) cmdlet and specify a key vault in the second region to clone the key. Alternatively, use the Azure portal to back up and restore the key. Key backup/restore operation is only allowed between key vaults within the same Azure subscription and [Azure geography](https://azure.microsoft.com/global-infrastructure/geographies/).
187
+
Alternatively, it can be accomplished by generating key using the primary key vault colocated in the same region as the server and cloning the key into a key vault in a different Azure region. Use the [Backup-AzKeyVaultKey](/powershell/module/az.keyvault/Backup-AzKeyVaultKey) cmdlet to retrieve the key in encrypted format from the primary key vault and then use the [Restore-AzKeyVaultKey](/powershell/module/az.keyvault/restore-azkeyvaultkey) cmdlet and specify a key vault in the second region to clone the key. Alternatively, use the Azure portal to back up and restore the key. Key backup/restore operation is only allowed between key vaults within the same Azure subscription and [Azure geography](https://azure.microsoft.com/global-infrastructure/geographies/).
In both [active geo-replication](active-geo-replication-overview.md) and [failover groups](auto-failover-group-overview.md) scenarios, each server involved requires a separate key vault, that must be co-located with the server in the same Azure region. Customer is responsible for keeping the key material across the key vaults consistent, so that geo-secondary is in sync and can take over using the same key from its local key vault if primary becomes inaccessible due to an outage in the region and a failover is triggered. Up to four secondaries can be configured, and chaining (secondaries of secondaries) is not supported.
193
+
In both [active geo-replication](active-geo-replication-overview.md) and [failover groups](auto-failover-group-overview.md) scenarios, each server involved requires a separate key vault, that must be colocated with the server in the same Azure region. Customer is responsible for keeping the key material across the key vaults consistent, so that geo-secondary is in sync and can take over using the same key from its local key vault if primary becomes inaccessible due to an outage in the region and a failover is triggered. Up to four secondaries can be configured, and chaining (secondaries of secondaries) is not supported.
194
194
195
195
To avoid issues while establishing or during geo-replication due to incomplete key material, it's important to follow these rules when configuring customer-managed TDE:
196
196
@@ -202,7 +202,7 @@ To avoid issues while establishing or during geo-replication due to incomplete k
202
202
203
203
204
204
205
-
To test a failover, follow the steps in [Active geo-replication overview](active-geo-replication-overview.md). Testing failover should be done on a regular basis to validate that SQL Database has maintained access permission to both key vaults.
205
+
To test a failover, follow the steps in [Active geo-replication overview](active-geo-replication-overview.md). Testing failover should be done regularly to validate that SQL Database has maintained access permission to both key vaults.
description: "Learn how to respond to a potentially compromised TDE protector for Azure SQL Database or Azure Synapse Analytics using TDE with Bring YOur Own Key (BYOK) support."
4
+
description: "Learn how to respond to a potentially compromised TDE protector for Azure SQL Database or Azure Synapse Analytics using TDE with Bring Your Own Key (BYOK) support."
0 commit comments