branding

Author: Ja-Dunn

articles/mysql/concepts-data-encryption-mysql.md

@@ -46,21 +46,21 @@ The DEKs, encrypted with the KEKs, are stored separately. Only an entity with ac
 
 For a MySQL server to use customer-managed keys stored in Key Vault for encryption of the DEK, a Key Vault administrator gives the following access rights to the server:
 
-* **get**: For retrieving the public part and properties of the key in the Key Vault.
+* **get**: For retrieving the public part and properties of the key in the key vault.
 * **wrapKey**: To be able to encrypt the DEK.
 * **unwrapKey**: To be able to decrypt the DEK.
 
-The Key Vault administrator can also [enable logging of Key Vault audit events](../azure-monitor/insights/azure-key-vault.md), so they can be audited later.
+The key vault administrator can also [enable logging of Key Vault audit events](../azure-monitor/insights/azure-key-vault.md), so they can be audited later.
 
-When the server is configured to use the customer-managed key stored in the Key Vault, the server sends the DEK to the Key Vault for encryptions. Key Vault returns the encrypted DEK, which is stored in the user database. Similarly, when needed, the server sends the protected DEK to the Key Vault for decryption. Auditors can use Azure Monitor to review Key Vault audit event logs, if logging is enabled.
+When the server is configured to use the customer-managed key stored in the key vault, the server sends the DEK to the key vault for encryptions. Key Vault returns the encrypted DEK, which is stored in the user database. Similarly, when needed, the server sends the protected DEK to the key vault for decryption. Auditors can use Azure Monitor to review Key Vault audit event logs, if logging is enabled.
 
 ## Requirements for configuring data encryption for Azure Database for MySQL
 
 The following are requirements for configuring Key Vault:
 
 * Key Vault and Azure Database for MySQL must belong to the same Azure Active Directory (Azure AD) tenant. Cross-tenant Key Vault and server interactions aren't supported. Moving resources afterwards requires you to reconfigure the data encryption.
-* You must enable the soft-delete feature on the Key Vault, to protect from data loss if an accidental key (or Key Vault) deletion happens. Soft-deleted resources are retained for 90 days, unless the user recovers or purges them in the meantime. The recover and purge actions have their own permissions associated in a Key Vault access policy. The soft-delete feature is off by default, but you can enable it through PowerShell or the Azure CLI (note that you can't enable it through the Azure portal).
-* Grant the Azure Database for MySQL access to the Key Vault with the get, wrapKey, and unwrapKey permissions by using its unique managed identity. In the Azure portal, the unique identity is automatically created when data encryption is enabled on the MySQL. See [Configure data encryption for MySQL](howto-data-encryption-portal.md) for detailed, step-by-step instructions when you're using the Azure portal.
+* You must enable the soft-delete feature on the key vault, to protect from data loss if an accidental key (or Key Vault) deletion happens. Soft-deleted resources are retained for 90 days, unless the user recovers or purges them in the meantime. The recover and purge actions have their own permissions associated in a Key Vault access policy. The soft-delete feature is off by default, but you can enable it through PowerShell or the Azure CLI (note that you can't enable it through the Azure portal).
+* Grant the Azure Database for MySQL access to the key vault with the get, wrapKey, and unwrapKey permissions by using its unique managed identity. In the Azure portal, the unique identity is automatically created when data encryption is enabled on the MySQL. See [Configure data encryption for MySQL](howto-data-encryption-portal.md) for detailed, step-by-step instructions when you're using the Azure portal.
 
 * When you're using a firewall with Key Vault, you must enable the option **Allow trusted Microsoft services to bypass the firewall**.
 
@@ -69,7 +69,7 @@ The following are requirements for configuring the customer-managed key:
 * The customer-managed key to be used for encrypting the DEK can be only asymmetric, RSA 2028.
 * The key activation date (if set) must be a date and time in the past. The expiration date (if set) must be a future date and time.
 * The key must be in the *Enabled* state.
-* If you're importing an existing key into the Key Vault, make sure to provide it in the supported file formats (`.pfx`, `.byok`, `.backup`).
+* If you're importing an existing key into the key vault, make sure to provide it in the supported file formats (`.pfx`, `.byok`, `.backup`).
 
 ## Recommendations
 
@@ -94,10 +94,10 @@ When you configure data encryption with a customer-managed key in Key Vault, con
 
 It might happen that someone with sufficient access rights to Key Vault accidentally disables server access to the key by:
 
-* Revoking Key Vault's get, wrapKey, and unwrapKey permissions from the server.
+* Revoking the key vault's get, wrapKey, and unwrapKey permissions from the server.
 * Deleting the key.
 * Deleting the key vault.
-* Changing Key Vault's firewall rules.
+* Changing the key vault's firewall rules.
 
 * Deleting the managed identity of the server in Azure AD.
 

articles/postgresql/concepts-data-encryption-postgresql.md

@@ -46,21 +46,21 @@ The DEKs, encrypted with the KEKs, are stored separately. Only an entity with ac
 
 For a PostgreSQL server to use customer-managed keys stored in Key Vault for encryption of the DEK, a Key Vault administrator gives the following access rights to the server:
 
-* **get**: For retrieving the public part and properties of the key in the Key Vault.
+* **get**: For retrieving the public part and properties of the key in the key vault.
 * **wrapKey**: To be able to encrypt the DEK.
 * **unwrapKey**: To be able to decrypt the DEK.
 
-The Key Vault administrator can also [enable logging of Key Vault audit events](../azure-monitor/insights/azure-key-vault.md), so they can be audited later.
+The key vault administrator can also [enable logging of Key Vault audit events](../azure-monitor/insights/azure-key-vault.md), so they can be audited later.
 
-When the server is configured to use the customer-managed key stored in the Key Vault, the server sends the DEK to the Key Vault for encryptions. Key Vault returns the encrypted DEK, which is stored in the user database. Similarly, when needed, the server sends the protected DEK to the Key Vault for decryption. Auditors can use Azure Monitor to review Key Vault audit event logs, if logging is enabled.
+When the server is configured to use the customer-managed key stored in the key vault, the server sends the DEK to the key vault for encryptions. Key Vault returns the encrypted DEK, which is stored in the user database. Similarly, when needed, the server sends the protected DEK to the key vault for decryption. Auditors can use Azure Monitor to review Key Vault audit event logs, if logging is enabled.
 
 ## Requirements for configuring data encryption for Azure Database for PostgreSQL Single server
 
 The following are requirements for configuring Key Vault:
 
 * Key Vault and Azure Database for PostgreSQL Single server must belong to the same Azure Active Directory (Azure AD) tenant. Cross-tenant Key Vault and server interactions aren't supported. Moving resources afterwards requires you to reconfigure the data encryption.
-* You must enable the soft-delete feature on the Key Vault, to protect from data loss if an accidental key (or Key Vault) deletion happens. Soft-deleted resources are retained for 90 days, unless the user recovers or purges them in the meantime. The recover and purge actions have their own permissions associated in a Key Vault access policy. The soft-delete feature is off by default, but you can enable it through PowerShell or the Azure CLI (note that you can't enable it through the Azure portal).
-* Grant the Azure Database for PostgreSQL Single server access to the Key Vault with the get, wrapKey, and unwrapKey permissions by using its unique managed identity. In the Azure portal, the unique identity is automatically created when data encryption is enabled on the PostgreSQL Single server. See [Data encryption for Azure Database for PostgreSQL Single server by using the Azure portal](howto-data-encryption-portal.md) for detailed, step-by-step instructions when you're using the Azure portal.
+* You must enable the soft-delete feature on the key vault, to protect from data loss if an accidental key (or Key Vault) deletion happens. Soft-deleted resources are retained for 90 days, unless the user recovers or purges them in the meantime. The recover and purge actions have their own permissions associated in a Key Vault access policy. The soft-delete feature is off by default, but you can enable it through PowerShell or the Azure CLI (note that you can't enable it through the Azure portal).
+* Grant the Azure Database for PostgreSQL Single server access to the key vault with the get, wrapKey, and unwrapKey permissions by using its unique managed identity. In the Azure portal, the unique identity is automatically created when data encryption is enabled on the PostgreSQL Single server. See [Data encryption for Azure Database for PostgreSQL Single server by using the Azure portal](howto-data-encryption-portal.md) for detailed, step-by-step instructions when you're using the Azure portal.
 
 * When you're using a firewall with Key Vault, you must enable the option **Allow trusted Microsoft services to bypass the firewall**.
 
@@ -69,7 +69,7 @@ The following are requirements for configuring the customer-managed key:
 * The customer-managed key to be used for encrypting the DEK can be only asymmetric, RSA 2028.
 * The key activation date (if set) must be a date and time in the past. The expiration date (if set) must be a future date and time.
 * The key must be in the *Enabled* state.
-* If you're importing an existing key into the Key Vault, make sure to provide it in the supported file formats (`.pfx`, `.byok`, `.backup`).
+* If you're importing an existing key into the key vault, make sure to provide it in the supported file formats (`.pfx`, `.byok`, `.backup`).
 
 ## Recommendations
 
@@ -94,10 +94,10 @@ When you configure data encryption with a customer-managed key in Key Vault, con
 
 It might happen that someone with sufficient access rights to Key Vault accidentally disables server access to the key by:
 
-* Revoking Key Vault's get, wrapKey, and unwrapKey permissions from the server.
+* Revoking the key vault's get, wrapKey, and unwrapKey permissions from the server.
 * Deleting the key.
 * Deleting the key vault.
-* Changing Key Vault's firewall rules.
+* Changing the key vault's firewall rules.
 
 * Deleting the managed identity of the server in Azure AD.