PR review feedback

Author: rmca14

articles/oracle/oracle-db/manage-oracle-transparent-data-encryption-azure-key-vault.md

@@ -11,7 +11,7 @@ ms.author: jacobjaygbay
 ---
 
 # Oracle Exadata Database with Azure Key Vault
-Exadata Database Service on Oracle Database@Azure now supports storing and managing Oracle Transparent Data Encryption (TDE) master encryption keys(MEK) using all three tiers of Azure Key Vault (AKV) services:
+Exadata Database Service on Oracle Database@Azure now supports storing and managing Oracle Transparent Data Encryption (TDE) master encryption keys (MEK) using all three tiers of Azure Key Vault (AKV) services:
 
 * **AKV Standard**
 * **AKV Premium**
@@ -21,7 +21,7 @@ This integration enables Oracle Database@Azure customers to meet a wide spectrum
 
 ## Step-by-step integration guide
 
-Integrating **Oracle Database@Azure** (Exadata VM Cluster) with **Azure Key Vault** (AKV) allows you to store and manage Oracle Transparent Data Encryption (TDE) master encryption keys(MEK) in Azure’s secure vault, enhancing security and simplifying key lifecycle management.  
+Integrating **Oracle Database@Azure** (Exadata VM Cluster) with **Azure Key Vault** (AKV) allows you to store and manage Oracle Transparent Data Encryption (TDE) master encryption keys (MEK) in Azure’s secure vault, enhancing security and simplifying key lifecycle management.  
 
 ## Prerequisites and assumptions
 
@@ -35,8 +35,8 @@ You have an **Exadata VM cluster** deployed in Azure via Oracle Database@Azure.
 * **Private Link Scope and Private Endpoint configuration for Azure Arc (optional)**: If using Private Link for the Azure Arc agent installation, the Azure Arc Private Link Scope and Private Endpoint must be configured and reachable from Exadata. DNS must also be configured and endpoints resolvable from Exadata.
 * **Azure subscription and permissions**: You have sufficient Azure permissions:
     * Azure role **Owner/contributor** on the subscription or resource group where Key Vault is created (to create resources and assign roles).
-    * Azure Entra ID **User Administrator** (or equivalent) if you create security groups for managing permissions.
-    * Azure **Global Administrator** is not required, but you should be able to obtain an Azure Entra ID access token for Arc registration (explained in Step 3).
+    * Microsoft Entra ID **User Administrator** (or equivalent) if you create security groups for managing permissions.
+    * Azure **Global Administrator** is not required, but you should be able to obtain a Microsoft Entra ID access token for Arc registration (explained in Step 3).
 * **OCI privileges**: In OCI (Oracle Cloud Infrastructure console), ensure you have permission to manage the multicloud integration.
 
 ## Step 1: Create and prepare an Azure Key Vault
@@ -60,18 +60,18 @@ You have an **Exadata VM cluster** deployed in Azure via Oracle Database@Azure.
 
     At this point, you have an Azure Key Vault (or HSM) ready, with a master key that is used for Oracle TDE. Next, we need to set up permissions so that the Oracle Exadata VM cluster can access this vault and key securely.
 
-## Step 2: Configure Azure Entra ID permissions for Key Vault access
+## Step 2: Configure Microsoft Entra ID permissions for Key Vault access
 
-**Goal**: Allow the Oracle Exadata VM Cluster (specifically, the Azure Arc identity of its VMs) to access the Key Vault and perform key operations (like unwrap keys, create new key versions for rotation, etc.), without over-privileging. We achieve this via Azure Entra ID Role-Based Access Control (RBAC). The general approach is:
+**Goal**: Allow the Oracle Exadata VM Cluster (specifically, the Azure Arc identity of its VMs) to access the Key Vault and perform key operations (like unwrap keys, create new key versions for rotation, etc.), without over-privileging. We achieve this via Microsoft Entra ID Role-Based Access Control (RBAC). The general approach is:
 
-* Create a security group in Azure Entra ID.
+* Create a security group in Microsoft Entra ID.
 * After the Oracle VM Cluster is Arc-enabled (next step), add the machine’s managed identity to this group.
 * Assign Key Vault roles to the group.
 
 This way, if you have multiple database VMs or clusters, you can manage their access via group membership and roles.
 
-1. **Create an Azure Entra ID security group** (optional but recommended):  
-    * You can create a group via Azure portal (Azure Entra ID blade > Groups > New Group) or CLI:
+1. **Create an Microsoft Entra ID security group** (optional but recommended):  
+    * You can create a group via Azure portal (Microsoft Entra ID blade > Groups > New Group) or CLI:
 
     Make note of the $GROUP_OBJECT_ID. This group remains empty for now. We add members in Step 3 after the Arc connector is set up (because the identities that need access is created during that process).
 2. **Assign Azure Key Vault roles**: We assign two roles to the security principal (the group, in this case) for the Key Vault:
@@ -80,20 +80,20 @@ This way, if you have multiple database VMs or clusters, you can manage their ac
 3. Using Azure CLI, assign these roles on the Key Vault scope:
 
 > [!NOTE]
-> If you prefer to use Key Vault access policies instead of RBAC, you could use az keyvault set-policy to allow an Entra ID principal to perform "nwrap key"and "et key" operations. However, the RBAC method shown is the modern approach and aligns with Oracle’s documented roles.
+> If you prefer to use Key Vault access policies instead of RBAC, you could use az keyvault set-policy to allow an Entra ID principal to perform "nwrap key" and "et key" operations. However, the RBAC method shown is the modern approach and aligns with Oracle’s documented roles.
 
 4. For **Managed HSM**:
     * Azure RBAC uses a different set of roles. According to Oracle’s guidance, for Managed HSM you should assign the Azure RBAC Reader role for the HSM resource. Then, use the HSM local RBAC to assign "Managed HSM Crypto Officer" and "Managed HSM Crypto User" to your principal. This can be done in the Azure portal’s Managed HSM access control page. The security group can also be used for these assignments. Ensure that the principal has been added as an HSM Crypto Officer at minimum. Crypto Officer can generate new key versions for rotation, and Crypto User can use the keys.
 
 5. **Double-check roles**: After assignments, you can verify:
     This should list the roles assigned to the group for the vault. There’s no harm in completing this role assignment step now. If the group has no members yet, the permissions are not used until a member is added.
 
-    At this stage, Azure is configured: you have a vault with a key, and an Azure Entra ID group with appropriate access to that vault. Now we move to the Oracle side to set up the integration.
+    At this stage, Azure is configured: you have a vault with a key, and a Microsoft Entra ID group with appropriate access to that vault. Now we move to the Oracle side to set up the integration.
 
 ## Step 3: Set Up the Oracle Identity Connector
 **Goal**: Set up the Oracle Identity Connector. This automatically configures the Azure Arc Agent to allow communication with Azure services (Key Vault) using an Azure identity.  
 
-When you create an Identity Connector via the OCI console, each VM in the cluster is registered as an Azure Arc-enabled server in your Azure subscription. This grants the VMs an identity in Azure Entra ID (a managed identity) which is applied for Key Vault access.
+When you create an Identity Connector via the OCI console, each VM in the cluster is registered as an Azure Arc-enabled server in your Azure subscription. This grants the VMs an identity in Microsoft Entra ID (a managed identity) which is applied for Key Vault access.
 
 Here’s how to create the connector:
 
@@ -124,7 +124,7 @@ Here’s how to create the connector:
         * Enter the Azure Arc Private Link Scope name you created from Azure portal when setting up private link for Arc. For example, the resource name of type *Microsoft.HybridCompute/privateLinkScopes*.
         * Make sure any required DNS or networking for private link is in place per Microsoft’s docs. If you're using the simpler NAT approach, you can leave this blank.
 
-        :::image type="content" source="media/oracle-identity-connector-info-adv-options.png" alt-text="Screenshot that shows where to find advanced options for identity connector information.":::
+        :::image type="content" source="media/oracle-identity-connector-info-advanced-options.png" alt-text="Screenshot that shows where to find advanced options for identity connector information.":::
     * Click Create to create the identity connector.
 
     The Oracle platform uses the token to register the Arc agent:
@@ -135,14 +135,14 @@ Here’s how to create the connector:
     ### Troubleshooting tip 
     If the connector creation fails, double-check the token (it might have expired – generate a fresh one) and Tenant ID. Also verify that the Azure subscription ID and resource group displayed are correct. The user generating the token must have rights to create Arc resources (Azure automatically creates a service principal for the Arc agent. Make sure the Azure resource provider Microsoft.HybridCompute is registered in your subscription).
 
-3. **Add Arc Machine Identities to Azure Entra ID group**: Once the connector is up, your Exadata VMs now each has a managed identity in Azure Entra ID. We need to grant these identities the Key Vault access (set up in Step 2). If you used a security group:
-    * Find the object IDs of the new Arc server identities. In Azure portal, go to the Azure Entra ID blade > Entities > Enterprise applications or the Azure Arc resource – the principal Object ID might be listed. An easier way: use Azure CLI to list Azure Arc connected machines and get their principal IDs:
+3. **Add Arc Machine Identities to Microsoft Entra ID group**: Once the connector is up, your Exadata VMs now each has a managed identity in Microsoft Entra ID. We need to grant these identities the Key Vault access (set up in Step 2). If you used a security group:
+    * Find the object IDs of the new Arc server identities. In Azure portal, go to the Microsoft Entra ID blade > Entities > Enterprise applications or the Azure Arc resource – the principal Object ID might be listed. An easier way: use Azure CLI to list Azure Arc connected machines and get their principal IDs:
 
     Each Arc machine has an identity with a principalId. Alternatively:
 
     You should see a JSON with a principalId (object ID) for the system-assigned identity.
 
-    * Add each Arc machine’s principalId as a member of the Azure Entra ID group created in Step 2. You can do this in Azure Entra ID portal (Group > Members > Add), or CLI:
+    * Add each Arc machine’s principalId as a member of the Microsoft Entra ID group created in Step 2. You can do this in Microsoft Entra ID portal (Group > Members > Add), or CLI:
 
     If you didn't use a group, you can instead assign the Key Vault roles directly to each principalId of the VM’s managed identity using az role assignment create similar to above, but with assignee-principal-type **ServicePrincipal** and the principalId. Using a group is cleaner for multiple nodes.
 
@@ -222,8 +222,7 @@ Using the OCI Console:
 * On the Database Information tab, find the Encryption / Key Management section. It should show that it’s currently using Oracle Wallet if it hasn’t been changed yet.
 * Click the Change link next to the Key Management field.
 
-
-:::image type="content" source="media/oracle-change-key-management.png" alt-text="Screenshot that shows where to change key management in the OCI console.":::
+:::image type="content" source="media/oracle-change-key-management.png" alt-text="Screenshot that shows where to change key management in the OCI console."lightbox="media/oracle-change-key-management.png":::
 
 * A dialog or form appears to Change key management. Provide:
     * New Key Management: select **Azure Key Vault**.
@@ -284,7 +283,7 @@ With the integration in place, consider the following for ongoing operations:
 *  **Key lifecycle management**: Manage the lifecycle of the keys in Azure:
     * **Retention**: Don't immediately purge old key versions. Oracle TDE can only use the latest version, but older versions might be needed to open old backups or archive logs. It’s wise to keep old key versions disabled but recoverable for a certain period.
     * **Backup**: For Azure Key Vault (Standard/Premium), Microsoft manages high availability and recovery. For Managed HSM, you're responsible for backing up the HSM if needed. Follow Azure’s guidance for HSM backups if applicable.
-    * **Separation of duties**: Typically, DBAs handle Oracle side, and a security admin handles the Azure Key Vault side. Use Azure Key Vault access policies/RBAC to ensure DBAs can't tamper with keys beyond using them via the database, and conversely Azure Entra ID admins can't directly read database data – they only manage keys. Regularly audit who has access to the Key Vault.
+    * **Separation of duties**: Typically, DBAs handle Oracle side, and a security admin handles the Azure Key Vault side. Use Azure Key Vault access policies/RBAC to ensure DBAs can't tamper with keys beyond using them via the database, and conversely Microsoft Entra ID admins can't directly read database data – they only manage keys. Regularly audit who has access to the Key Vault.
 * **Disaster recovery (DR)**:
     * **Managed HSM**: Follow [Managed HSM Disaster Recovery Guide](/azure/key-vault/managed-hsm/disaster-recovery-guide?tabs=uami). For increased availability, [Enable multi-region replication on Azure Managed HSM](/azure/key-vault/managed-hsm/multi-region-replication).
     * **Standard and premium**: Automatic replication enabled for paired regions. For more information, see [Azure Key Vault availability and redundancy](/azure/key-vault/general/disaster-recovery-guidance).
@@ -319,7 +318,7 @@ With the integration in place, consider the following for ongoing operations:
 
 * **Monitoring and auditing**: Enable Azure Diagnostic Logs for monitoring key access and usage events across all tiers.
 
-*  **Dedicated vault**:    Use a dedicated Key Vault or a dedicated key for each Oracle environment. Don't reuse the same key for different databases – each CDB should have its own TDE master key.Oracle enforces this anyway. You can keep multiple keys in one vault (one per DB), which is fine.
+*  **Dedicated vault**:    Use a dedicated Key Vault or a dedicated key for each Oracle environment. Don't reuse the same key for different databases – each CDB should have its own TDE master key. Oracle enforces this anyway. You can keep multiple keys in one vault (one per DB), which is fine.
 
 Finally, remember that this integration bridges two cloud services – so ensure your support contracts with Oracle and Microsoft are in place. For any issues, you have the benefit of joint support: both companies have a partnership to help customers running this setup. Oracle’s support docs and Azure’s documentation can be referenced for troubleshooting known issues.