Updates

Author: msmbaldwin

articles/key-vault/managed-hsm/disaster-recovery-guide.md

@@ -1,13 +1,13 @@
 ---
-title: What to do if there if an Azure service disruption that affects Managed HSM - Azure Key Vault | Microsoft Docs
-description: Learn what to do f there is an Azure service disruption that affects Managed HSM.
+title: What to do if there's an Azure service disruption that affects Managed HSM - Azure Key Vault | Microsoft Docs
+description: Learn what to do if there's an Azure service disruption that affects Managed HSM.
 services: key-vault
 author: mbaldwin
 
 ms.service: key-vault
 ms.subservice: general
 ms.topic: tutorial
-ms.date: 09/15/2020
+ms.date: 01/04/2023
 ms.author: mbaldwin
 ---
 
@@ -27,7 +27,7 @@ Here are the steps of the disaster recovery procedure:
 
 1. Create a new HSM Instance.
 2. Activate "Security Domain recovery". A new RSA key pair (Security Domain Exchange Key) will be generated for Security Domain transfer and sent in response, which will be downloaded as a SecurityDomainExchangeKey (public key).
-3. Create and then upload the "Security Domain Transfer File". You will need the private keys that encrypt the security domain. The private keys are used locally, and never transferred anywhere in this process.
+3. Create and then upload the "Security Domain Transfer File". You'll need the private keys that encrypt the security domain. The private keys are used locally, and never transferred anywhere in this process.
 4. Take a backup of the new HSM. A backup is required before any restore, even when the HSM is empty. Backups allow for easy roll-back.
 5. Restore the recent HSM backup from the source HSM.
 
@@ -67,15 +67,15 @@ Your Azure account is now authorized to perform any operations on this Managed H
 
 ## Activate the Security Domain recovery mode
 
-At this point in the normal creation process, we initialize and download the new HSM's Security Domain. However, since we are executing a disaster recovery procedure, we request the HSM to enter Security Domain Recovery Mode and download a Security Domain Exchange Key instead. The Security Domain Exchange Key is an RSA public key that will be used to encrypt the security domain before uploading it to the HSM. The corresponding private key is protected inside the HSM, to keep your Security Domain contents safe during the transfer.
+At this point in the normal creation process, we initialize and download the new HSM's Security Domain. However, since we're executing a disaster recovery procedure, we request the HSM to enter Security Domain Recovery Mode and download a Security Domain Exchange Key instead. The Security Domain Exchange Key is an RSA public key that will be used to encrypt the security domain before uploading it to the HSM. The corresponding private key is protected inside the HSM, to keep your Security Domain contents safe during the transfer.
 
 ```azurecli-interactive
 az keyvault security-domain init-recovery --hsm-name ContosoMHSM2 --sd-exchange-key ContosoMHSM2-SDE.cer
 ```
 
 ## Upload Security Domain to destination HSM
 
-For this step you will need:
+For this step you'll need:
 - The Security Domain Exchange Key you downloaded in previous step.
 - The Security Domain of the source HSM.
 - At least quorum number of private keys that were used to encrypt the security domain.
@@ -96,9 +96,9 @@ Now both the source HSM (ContosoMHSM) and the destination HSM (ContosoMHSM2) hav
 
 ## Create a backup (as a restore point) of your new HSM
 
-It is always a good idea to take a full backup before you execute a full HSM restore, so that you have a restore point in case something goes wrong with the restore.
+It's always a good idea to take a full backup before you execute a full HSM restore, so that you have a restore point in case something goes wrong with the restore.
 
-To create an HSM backup, you will need:
+To create an HSM backup, you'll need:
 - A storage account where the backup will be stored
 - A blob storage container in this storage account where the backup process will create a new folder to store encrypted backup
 
@@ -117,7 +117,7 @@ az keyvault backup start --hsm-name ContosoMHSM2 --storage-account-name ContosoB
 
 For this step you need:
 
-- The storage account and the blob container where the source HSM's backups are stored.
+- The storage account and the blob container in which the source HSM's backups are stored.
 - The folder name from where you want to restore the backup. If you create regular backups, there will be many folders inside this container.
 
 
@@ -128,7 +128,7 @@ sas=$(az storage container generate-sas -n mhsmdemobackupcontainer --account-nam
 az keyvault restore start --hsm-name ContosoMHSM2 --storage-account-name ContosoBackup --blob-container-name mhsmdemobackupcontainer --storage-container-SAS-token $sas --backup-folder mhsm-ContosoMHSM-2020083120161860
 ```
 
-Now you have completed a full disaster recovery process. The contents of the source HSM when the backup was taken are copied to the destination HSM, including all the keys, versions, attributes, tags, and role assignments.
+Now you've completed a full disaster recovery process. The contents of the source HSM when the backup was taken are copied to the destination HSM, including all the keys, versions, attributes, tags, and role assignments.
 
 ## Next steps
 

articles/key-vault/managed-hsm/hsm-protected-keys-byok.md

@@ -7,7 +7,7 @@ tags: azure-resource-manager
 
 ms.service: key-vault
 ms.topic: conceptual
-ms.date: 02/04/2021
+ms.date: 01/04/2023
 ms.author: mbaldwin
 ---
 
@@ -30,8 +30,8 @@ Here's an overview of the process. Specific steps to complete are described late
 * Download the KEK public key as a .pem file.
 * Transfer the KEK public key to an offline computer that is connected to an on-premises HSM.
 * In the offline computer, use the BYOK tool provided by your HSM vendor to create a BYOK file. 
-* The target key is encrypted with a KEK, which stays encrypted until it is transferred to the Managed HSM. Only the encrypted version of your key leaves the on-premises HSM.
-* A KEK that's generated inside a Managed HSM is not exportable. HSMs enforce the rule that no clear version of a KEK exists outside a Managed HSM.
+* The target key is encrypted with a KEK, which stays encrypted until it's transferred to the Managed HSM. Only the encrypted version of your key leaves the on-premises HSM.
+* A KEK that's generated inside a Managed HSM isn't exportable. HSMs enforce the rule that no clear version of a KEK exists outside a Managed HSM.
 * The KEK must be in the same managed HSM where the target key will be imported.
 * When the BYOK file is uploaded to Managed HSM, a Managed HSM uses the KEK private key to decrypt the target key material and import it as an HSM key. This operation happens entirely inside the HSM. The target key always remains in the HSM protection boundary.
 
@@ -46,13 +46,13 @@ To use the Azure CLI commands in this article, you must have the following items
 
 [!INCLUDE [cloud-shell-try-it.md](../../../includes/cloud-shell-try-it.md)]
 
-To sign in to Azure using the CLI you can type:
+To sign in to Azure using the CLI, type:
 
 ```azurecli
 az login
 ```
 
-For more information on login options via the CLI take a look at [sign in with Azure CLI](/cli/azure/authenticate-azure-cli)
+For more information on login options via the CLI, take a look at [sign in with Azure CLI](/cli/azure/authenticate-azure-cli)
 
 ## Supported HSMs
 
@@ -101,7 +101,7 @@ The KEK must be:
 > [!NOTE]
 > The KEK must have 'import' as the only allowed key operation. 'import' is mutually exclusive with all other key operations.
 
-Use the [az keyvault key create](/cli/azure/keyvault/key#az-keyvault-key-create) command to create a KEK that has key operations set to `import`. Record the key identifier (`kid`) that's returned from the following command. (You will use the `kid` value in [Step 3](#step-3-generate-and-prepare-your-key-for-transfer).)
+Use the [az keyvault key create](/cli/azure/keyvault/key#az-keyvault-key-create) command to create a KEK that has key operations set to `import`. Record the key identifier (`kid`) that's returned from the following command. (You'll use the `kid` value in [Step 3](#step-3-generate-and-prepare-your-key-for-transfer).)
 
 ```azurecli-interactive
 az keyvault key create --kty RSA-HSM --size 4096 --name KEKforBYOK --ops import --hsm-name ContosoKeyVaultHSM
@@ -118,7 +118,7 @@ az keyvault key download --name KEKforBYOK --hsm-name ContosoKeyVaultHSM --file
 ```
 ---
 
-Transfer the KEKforBYOK.publickey.pem file to your offline computer. You will need this file in the next step.
+Transfer the KEKforBYOK.publickey.pem file to your offline computer. You'll need this file in the next step.
 
 ### Step 3: Generate and prepare your key for transfer