Update manage-oracle-transparent-data-encryption-azure-key-vault.md

taylorrees1 · web-flow · commit e092c7405b97 · 2025-07-15T15:36:15.000-07:00
updated from copyedit notes
diff --git a/articles/oracle/oracle-db/manage-oracle-transparent-data-encryption-azure-key-vault.md b/articles/oracle/oracle-db/manage-oracle-transparent-data-encryption-azure-key-vault.md
@@ -10,8 +10,8 @@ ms.custom: engagement-fy23
 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:
+# Integrate Oracle Exadata Database@Azure with Azure Key vault
+In this article, you learn to store and manage Oracle Transparent Data Encryption (TDE) master encryption keys (MEK) for Exadata Database Service on Oracle Database@Azure.  You can use all three tiers of the Azure Key Vault (AKV) services:  
 
 * **AKV Standard**
 * **AKV Premium**
@@ -28,23 +28,26 @@ High level architectural diagram
 Before beginning the integration, ensure the following prerequisites are met:
 
 * **Oracle Database@Azure provisioned**: You have an Exadata VM cluster deployed in a delegated subnet within an Azure Virtual Network and you have access to the Oracle Cloud Infrastructure (OCI) console for management.
-* **Advanced networking enabled**:If not already configured, ensure Advanced Networking Feature is enabled as per the [Network planning for Oracle Database@Azure | Microsoft Learn](/azure/oracle/oracle-db/oracle-database-network-plan)guide to enable Private Link connectivity required for Managed HSM and Azure Arc. 
-* **Azure Key Vault private connectivity**: Private Endpoint with DNS configuration for Azure Key Vault with has been configured and reachable by Exadata as per [Integrate Key Vault with Azure Private Link | Microsoft Learn](/azure/key-vault/general/private-link-service)
-* **NAT Gateway**: Outbound internet connectivity is required for the Identity Connector setup to access Microsoft Entra Public endpoint. This can be achieved by using an Azure NAT gateway, Azure Firewall or an NVA of your choice if you already not have one in the same VNET as your Oracle deployment or in the shared HUB if using Hub/spoke topology. 
+* **Advanced networking enabled**:If not already configured, ensure Advanced Networking feature is enabled as per the [Network planning for Oracle Database@Azure | Microsoft Learn](/azure/oracle/oracle-db/oracle-database-network-plan)guide to enable Private Link connectivity required for Managed HSM and Azure Arc. 
+* **Azure Key Vault private connectivity**: Private Endpoint with DNS configuration for Azure Key Vault has been configured and reachable by Exadata. For details, see  [Integrate Key Vault with Azure Private Link | Microsoft Learn](/azure/key-vault/general/private-link-service)
+* **NAT Gateway**: Outbound internet connectivity is required for the Identity Connector setup to access Microsoft Entra Public endpoint. This connectivity can be achieved by using an Azure NAT gateway, Azure Firewall or a Network Virtual Appliance (NVA) of your choice if you do not have one in the same VNET as your Oracle deployment or in the shared HUB if using Hub/spoke topology. 
 * **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).
     * 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. Oracle recommends an IAM policy in your OCI tenancy such as: 
+* **OCI privileges**: In the Oracle Cloud Infrastructure (OCI) console, ensure that you have permission to manage the multicloud integration. Oracle recommends an IAM policy in your OCI tenancy such as: 
 
    * *allow any-user to manage oracle-db-azure-vaults in tenancy*
    * *where request.principal.type = 'cloudvmcluster'*  
 
-This policy allows the Exadata VM Cluster resource to manage Key Vault associations. (Your cloud administrator might have already set this up; otherwise, it must be added by an OCI admin before configuring the database to use Azure Key Vault. 
+This IAM policy allows the Exadata VM Cluster resource to manage Key Vault associations. 
+
+>[!Note]
+>Your cloud administrator might have already set this up; otherwise, it must be added by an OCI admin before configuring the database to use Azure Key Vault. 
 ## Step 1: Create and prepare an Azure Key Vault
 
-**Goal**: Set up an Azure Key Vault to hold your Oracle database encryption keys. If you already have a suitable Key Vault and key, you can use it, but ensure it’s dedicated or appropriately secured for this purpose.
+Set up an Azure Key Vault to hold your Oracle database encryption keys. If you already have a suitable Key Vault and key, you can use it, but ensure it’s dedicated or appropriately secured for this purpose.
 
 1. **Create an Azure Key Vault**: You can use the Microsoft Azure portal or Azure CLI.  
     * **AKV Standard**: Follow [Azure Key Vault CLI Quickstart](/azure/key-vault/general/quick-create-cli)
@@ -59,37 +62,40 @@ This policy allows the Exadata VM Cluster resource to manage Key Vault associati
 
     **Why create the key now?** During vault registration, Oracle control plane checks that at least one key exists in the vault. If none is found, the vault registration fails. Creating a key upfront avoids that issue.
 
-3. **(For Managed HSM)**: If you chose Managed HSM, after provisioning, you must activate the HSM (if not already) and create a key in it (az keyvault key create --hsm-name <HSM_Name> -n $KEY_NAME ...). Also, note that Managed HSM uses a different permission model (local HSM roles). We’ll cover the role assignments in the next step.
+3. **(For Managed HSM)**: If you chose Managed HSM, after provisioning, you must activate the HSM (if not already) and create a key in it:
+      ```az keyvault key create --hsm-name <HSM_Name> -n $KEY_NAME ...```
+
+   Note that Managed HSM uses a different permission model (local HSM roles). We’ll cover the role assignments in the next step.
 
     At this point, you have an Azure Key Vault (or HSM) ready, with a master key that is used for Oracle TDE. Next step is to set up permissions so that the Oracle Exadata VM cluster can access this vault and key securely.
 
 ## 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. This can be acheived with Microsoft Entra ID Role-Based Access Control (RBAC). The general approach is:
+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. This can be achieved with Microsoft Entra ID Role-Based Access Control (RBAC). The general approach is as follows:
 
 * 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 Microsoft Entra ID security group** (optional but recommended):  
+1. **Create a Microsoft Entra ID security group** (optional, 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).
+    Make note of the $GROUP_OBJECT_ID. This group remains empty for now. You add members in [Step 3](#Step 3: Set Up the Oracle Identity Connector) after the Arc connector is set up; the identities needed to access the Arc connector is created in 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:
-    * **Key Vault crypto officer** – Allows management of keys (create, delete, list key versions) and performing cryptographic operations (unwrap/decrypt, etc.).
+    * **Key Vault crypto officer** – Allows management of keys (create, delete, list key versions) and performance of cryptographic operations (unwrap/decrypt, etc.).
     * **Key Vault reader** – Allows viewing Key Vault properties
 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, use az keyvault set-policy to allow an Entra ID principal to perform "nwrap key" and "et key" operations. However, the RBAC method 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.
 
 ## 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.  
+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 Microsoft Entra ID (a managed identity) which is applied for Key Vault access.
 
@@ -108,7 +114,7 @@ Here’s how to create the connector:
     * Log in to the OCI Console for Oracle Database@Azure. Navigate to your Exadata VM Cluster resource. (Menu: Oracle Database > Oracle Exadata Database Service on Dedicated Infrastructure > Exadata VM Clusters > click your cluster name.)
     * On the VM Cluster details page, find the "Multicloud Information" section. You should see an Identity Connector field, which likely shows "None" if not set up yet.
 
-        Click Create or Setup Connector. A form appears.
+        Select Create or Setup Connector. A form appears.
 
     :::image type="content" source="media/oracle-create-identity-connector.png" alt-text="Screenshot that shows where to select create for identity connector.":::  
 
@@ -131,9 +137,9 @@ Here’s how to create the connector:
     * Oracle’s console shows the Identity Connector status. Navigate to *Database Multicloud Integrations > Identity Connectors* to verify the connector exists. On the VM Cluster page, the Identity Connector field should now show the connector name instead of "None."
 
     ### 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).
+    If creating the connector 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 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:
+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](#Step 2: Configure Microsoft Entra ID permissions for Key Vault access). 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:
@@ -148,14 +154,14 @@ Here’s how to create the connector:
 
 ## Step 4: Enable Azure Key Vault key management on the VM Cluster
 
-**Goal**: Activate the Key Vault integration at the Exadata VM Cluster level. This installs the required Oracle library/plugin on the cluster VMs that allows databases to use Azure Key Vault as a keystore.
+Activate the Key Vault integration at the Exadata VM Cluster level. This installs the required Oracle library/plugin on the cluster VMs that allows databases to use Azure Key Vault as a keystore.
 
 In the OCI console:
 
 * Go to the Exadata VM Cluster details page where you created the connector.
 * In the Multicloud Information section, find Azure key store or Azure Key Management status. It should currently say "Disabled."
-* Click Enable next to Azure key store.
-* Confirm the action in the dialog that appears (click Enable).
+* Select Enable next to Azure key store.
+* Confirm the action in the dialog that appears (select Enable).
 
 :::image type="content" source="media/oracle-enable-azure-key-management.png" alt-text="Screenshot that shows where to Enable Azure key management in the OCI console.":::
 
