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: azure-sql/database/high-availability-sla.md
+3-3Lines changed: 3 additions & 3 deletions
Display the source diff
Display the rich diff
Original file line number
Diff line number
Diff line change
@@ -91,7 +91,7 @@ The zone-redundant version of the high availability architecture is illustrated
91
91
92
92
> [!IMPORTANT]
93
93
> - This feature is currently in preview for SQL Managed Instance, and only available on the Business Critical service tier. In SQL Database, when using the Business Critical tier, zone-redundant configuration is only available when the Gen5 hardware is selected. For up to date information about the regions that support zone-redundant databases, see [Services support by region](/azure/availability-zones/az-region).
94
-
> - For zone redundant availability, choosing a [maintenance window](/azure/azure-sql/database/maintenance-window) other than the default is currently available in [select regions](maintenance-window.md#azure-region-support).
94
+
> - For zone redundant availability, choosing a [maintenance window](./maintenance-window.md) other than the default is currently available in [select regions](maintenance-window.md#azure-region-support).
95
95
96
96
### Supported regions for SQL MI zone redundancy
97
97
@@ -138,7 +138,7 @@ Consider the following limitations:
138
138
> At least 1 high availability compute replica and the use of zone-redundant or geo-zone-redundant backup storage is required for enabling the zone redundant configuration for Hyperscale.
139
139
140
140
> [!IMPORTANT]
141
-
> For zone redundant availability, choosing a [maintenance window](/azure/azure-sql/database/maintenance-window) other than the default is currently available in [select regions](maintenance-window.md#azure-region-support).
141
+
> For zone redundant availability, choosing a [maintenance window](./maintenance-window.md) other than the default is currently available in [select regions](maintenance-window.md#azure-region-support).
142
142
143
143
144
144
### Create a zone redundant Hyperscale database
@@ -283,4 +283,4 @@ Azure SQL Database and Azure SQL Managed Instance feature a built-in high availa
283
283
- Learn about [Service Fabric](/azure/service-fabric/service-fabric-overview)
284
284
- Learn about [Azure Traffic Manager](/azure/traffic-manager/traffic-manager-overview)
285
285
- Learn [How to initiate a manual failover on SQL Managed Instance](../managed-instance/user-initiated-failover.md)
286
-
- For more options for high availability and disaster recovery, see [Business Continuity](business-continuity-high-availability-disaster-recover-hadr-overview.md)
286
+
- For more options for high availability and disaster recovery, see [Business Continuity](business-continuity-high-availability-disaster-recover-hadr-overview.md)
> Assigning a user-assigned managed identity for Azure SQL logical servers and Managed Instances is in **public preview**.
19
-
20
-
Managed identities in Azure Active Directory (Azure AD) provide Azure services with an automatically managed identity in Azure AD. This identity can be used to authenticate to any service that supports Azure AD authentication, such as [Azure Key Vault](/azure/key-vault/general/overview), without any credentials in the code. For more information, see [Managed identity types](/azure/active-directory/managed-identities-azure-resources/overview#managed-identity-types) in Azure.
17
+
Managed identities in Azure Active Directory (Azure AD) provide Azure services with an automatically managed identity in Azure AD. This identity can be used to authenticate to any service that supports Azure AD authentication, such as [Azure Key Vault](/azure/key-vault/general/overview), without any credentials in the code. For more information, see [Managed identity types](/azure/active-directory/managed-identities-azure-resources/overview#managed-identity-types) in Azure.
21
18
22
19
Managed Identities can be of two types:
23
20
24
21
-**System-assigned**
25
22
-**User-assigned**
26
23
27
-
Enabling system-assigned managed identity for Azure SQL logical servers and Managed Instances are already supported today. [Assigning user-assigned managed identity](authentication-azure-ad-user-assigned-managed-identity.md) to the server is now in public preview.
24
+
For more information, see [Managed identities in Azure AD for Azure SQL](authentication-azure-ad-user-assigned-managed-identity.md).
28
25
29
26
For [TDE with customer-managed key (CMK)](transparent-data-encryption-byok-overview.md) in Azure SQL, a managed identity on the server is used for providing access rights to the server on the key vault. For instance, the system-assigned managed identity of the server should be provided with [key vault permissions](transparent-data-encryption-byok-overview.md#how-customer-managed-tde-works) prior to enabling TDE with CMK on the server.
30
27
@@ -41,29 +38,34 @@ In addition to the system-assigned managed identity that is already supported fo
41
38
42
39
- Enables the same user-assigned managed identity to be assigned to multiple servers, eliminating the need to individually turn on system-assigned managed identity for each Azure SQL logical server or managed instance, and providing it access to key vault
43
40
44
-
- Provides the capability to enforce CMK at server or database creation time with an available built-in Azure policy
41
+
- Provides the capability to enforce CMK at server creation time with an available built-in Azure policy
45
42
46
43
## Considerations while using UMI for customer-managed TDE
47
44
48
45
- By default, TDE in Azure SQL uses the primary user-assigned managed identity set on the server for key vault access. If no user-assigned identities have been assigned to the server, then the system-assigned managed identity of the server is used for key vault access.
49
-
- When using the system-assigned managed identity for TDE with CMK, no user-assigned managed identities should be assigned to the server
50
46
- When using a user-assigned managed identity for TDE with CMK, assign the identity to the server and set it as the primary identity for the server
51
-
- The primary user-assigned managed identity requires continuous key vault access (*get, wrapKey, unwrapKey* permissions). If the identity's access to key vault is revoked or sufficient permissions are not provided, the database will move to *Inaccessible* state
47
+
- The primary user-assigned managed identity requires continuous key vault access (*get, wrapKey, unwrapKey* permissions). If the identity's access to key vault is revoked or sufficient permissions aren't provided, the database will move to *Inaccessible* state
52
48
- If the primary user-assigned managed identity is being updated to a different user-assigned managed identity, the new identity must be given required permissions to the key vault prior to updating the primary
53
49
- To switch the server from user-assigned to system-assigned managed identity for key vault access, provide the system-assigned managed identity with the required key vault permissions, then remove all user-assigned managed identities from the server
54
50
55
-
> [!Important]
51
+
> [!IMPORTANT]
56
52
> The primary user-assigned managed identity being used for TDE with CMK should not be deleted from Azure. Deleting this identity will lead to the server losing access to key vault and databases becoming *inaccessible*.
57
-
53
+
58
54
## Limitations and known issues
59
55
60
-
- If the key vault is behind a VNet, a user-assigned managed identity cannot be used with customer-managed TDE. A system-assigned managed identity must be used in this case. A user-assigned managed identity can only be used when the key vault is not behind a VNet.
61
-
- When multiple user-assigned managed identities are assigned to the server or managed instance, if a single identity is removed from the server using the *Identity* blade of the Azure Portal, the operation succeeds but the identity does not get removed from the server. Removing all user-assigned managed identities together from the Azure portal works successfully.
62
-
- When the server or managed instance is configured with customer-managed TDE and both system-assigned and user-assigned managed identities are enabled on the server, removing the user-assigned managed identities from the server without first giving the system-assigned managed identity access to the key vault results in an *Unexpected error occurred* message. Ensure the system-assigned managed identity has been provided key vault access prior to removing the primary user-assigned managed identity (and any other user-assigned managed identities) from the server.
56
+
- If the key vault is behind a VNet that uses a firewall, the option to **Allow Trusted Microsoft Services to bypass this firewall** must be enabled in the key vault's **Networking** menu if you want to use a user-assigned managed identity. Once this option is enabled, available keys can't be listed in the SQL server TDE menu in the Azure portal. To set an individual CMK, a *key identifier* must be used. When the option to **Allow Trusted Microsoft Services to bypass this firewall** isn't enabled, the following error is returned:
57
+
-`The managed identity with ID '/subscriptions/subsriptionID/resourcegroups/resource_name/providers/Microsoft.ManagedIdentity/userAssignedIdentities/umi_name' requires the following Azure Key Vault permissions: 'Get, WrapKey, UnwrapKey' to the key 'https://keyvault_name/keys/key_name'. Please grant the missing permissions to the identity. (https://aka.ms/sqltdebyokcreateserver).`
58
+
- If you get the above error, check if the key vault is behind a virtual network or firewall, and make sure the option **Allow Trusted Microsoft Services to bypass this firewall** is enabled.
59
+
- A system-assigned managed identity can be used without the option to **Allow Trusted Microsoft Services to bypass this firewall** enabled. For more information, see [Configure Azure Key Vault firewalls and virtual networks](/azure/key-vault/general/network-security).
63
60
- User Assigned Managed Identity for SQL Managed Instance is currently not supported when AKV firewall is enabled.
64
-
61
+
- When multiple user-assigned managed identities are assigned to the server or managed instance, if a single identity is removed from the server using the *Identity* blade of the Azure portal, the operation succeeds but the identity doesn't get removed from the server. Removing all user-assigned managed identities together from the Azure portal works successfully.
62
+
- When the server or managed instance is configured with customer-managed TDE and both system-assigned and user-assigned managed identities are enabled on the server, removing the user-assigned managed identities from the server without first giving the system-assigned managed identity access to the key vault results in an *Unexpected error occurred* message. Ensure the system-assigned managed identity has been provided key vault access prior to removing the primary user-assigned managed identity (and any other user-assigned managed identities) from the server.
65
63
66
64
## Next steps
67
65
68
66
> [!div class="nextstepaction"]
69
67
> [Create Azure SQL database configured with user-assigned managed identity and customer-managed TDE](transparent-data-encryption-byok-create-server.md)
68
+
69
+
## See also
70
+
71
+
-[Create an Azure SQL Managed Instance with a user-assigned managed identity](/azure/azure-sql/managed-instance/authentication-azure-ad-user-assigned-managed-identity-create-managed-instance)
Copy file name to clipboardExpand all lines: azure-sql/database/transparent-data-encryption-byok-overview.md
+7-7Lines changed: 7 additions & 7 deletions
Display the source diff
Display the rich diff
Original file line number
Diff line number
Diff line change
@@ -5,7 +5,7 @@ description: Bring Your Own Key (BYOK) support for transparent data encryption (
5
5
author: GithubMirek
6
6
ms.author: mireks
7
7
ms.reviewer: wiassaf, vanto, mathoma
8
-
ms.date: 10/17/2022
8
+
ms.date: 11/21/2022
9
9
ms.service: sql-db-mi
10
10
ms.subservice: security
11
11
ms.topic: conceptual
@@ -79,7 +79,7 @@ Auditors can use Azure Monitor to review key vault AuditEvent logs, if logging i
79
79
- Grant the server or managed instance access to the key vault (*get*, *wrapKey*, *unwrapKey*) using its Azure Active Directory identity. The server identity can be a system-assigned managed identity or a user-assigned managed identity assigned to the server. When using the Azure portal, the Azure AD identity gets automatically created when the server is created. When using PowerShell or Azure CLI, the Azure AD identity must be explicitly created and should be verified. See [Configure TDE with BYOK](transparent-data-encryption-byok-configure.md) and [Configure TDE with BYOK for SQL Managed Instance](../managed-instance/scripts/transparent-data-encryption-byok-powershell.md) for detailed step-by-step instructions when using PowerShell.
80
80
- Depending on the permission model of the key vault (access policy or Azure RBAC), key vault access can be granted either by creating an access policy on the key vault, or by creating a new Azure RBAC role assignment with the role [Key Vault Crypto Service Encryption User](/azure/key-vault/general/rbac-guide#azure-built-in-roles-for-key-vault-data-plane-operations).
81
81
82
-
- When using firewall with AKV, you must enable option *Allow trusted Microsoft services to bypass the firewall*.
82
+
- When using a firewall with AKV, you must enable the option **Allow trusted Microsoft services to bypass the firewall**. For more information, see [Configure Azure Key Vault firewalls and virtual networks](/azure/key-vault/general/network-security).
83
83
84
84
### Enable soft-delete and purge protection for AKV
85
85
@@ -198,21 +198,21 @@ Learn more about [the common causes for database to become inaccessible](/sql/re
198
198
199
199
### Blocked connectivity between SQL Managed Instance and Key Vault
200
200
201
-
On SQL Managed Instance, network errors while trying to access TDE protector in Azure Key Vault may not cause the databases to change its state to *Inaccessible* but will render the instance unavailable afterwards. This happens mostly when the key vault resource exists but it's endpoint cannot be reached from the managed instance. All scenarios where the key vault endpoint can be reached but connection is denied, missing permissions, etc., will cause the databases to change its state to *Inaccessible*.
201
+
On SQL Managed Instance, network errors while trying to access TDE protector in Azure Key Vault may not cause the databases to change its state to *Inaccessible* but will render the instance unavailable afterwards. This happens mostly when the key vault resource exists but its endpoint can't be reached from the managed instance. All scenarios where the key vault endpoint can be reached but connection is denied, missing permissions, etc., will cause the databases to change its state to *Inaccessible*.
202
202
203
203
The most common causes for lack of networking connectivity to Key Vault are:
204
204
205
-
- Key Vault is exposed via private endpoint and the private IP address of the AKV service is not allowed in the outbound rules of the Network Security Group (NSG) associated with the managed instance subnet.
206
-
- Bad DNS resolution, like when the key vault FQDN is not resolved or resolves to an invalid IP address.
205
+
- Key Vault is exposed via private endpoint and the private IP address of the AKV service isn't allowed in the outbound rules of the Network Security Group (NSG) associated with the managed instance subnet.
206
+
- Bad DNS resolution, like when the key vault FQDN isn't resolved or resolves to an invalid IP address.
207
207
208
208
[Test the connectivity](https://techcommunity.microsoft.com/t5/azure-sql-blog/how-to-test-tcp-connectivity-from-a-sql-managed-instance/ba-p/3058458) from SQL Managed Instance to the Key Vault hosting the TDE protector.
209
209
210
210
- The endpoint is your vault FQDN, like *<vault_name>.vault.azure.net* (without the https://).
211
211
- The port to be tested is 443.
212
212
- The result for RemoteAddress should exist and be the correct IP address
213
-
- The result for TCP test should be *TcpTestSucceeded: True*.
213
+
- The result for TCP test should be *TcpTestSucceeded: True*.
214
214
215
-
In case the test returns *TcpTestSucceeded: False*, review the networking configuration:
215
+
In case the test returns *TcpTestSucceeded: False*, review the networking configuration:
216
216
217
217
- Check the resolved IP address, confirm it's valid. A missing value means there's issues with DNS resolution.
218
218
- Confirm that the network security group on the managed instance has an **outbound** rule that covers the resolved IP address on port 443, especially when the resolved address belongs to the key vault's private endpoint.
0 commit comments