Security Best Practices for Oracle Database@Azure
Security Best Practices for Oracle Database@Azure
Article Overview
Security on Oracle Database@Azure is unusual because two vendors' security stacks meet at the database. Oracle owns the engine and its native controls — Transparent Data Encryption, Database Vault, Data Safe, SQL Firewall. Azure owns the identity, key management, network, and monitoring planes — Entra ID, Key Vault, private endpoints, Defender, Sentinel. Getting security right means using each one where it is strongest and understanding exactly where the boundary sits. This guide walks the full defense-in-depth stack layer by layer, with the configuration that matters: encrypting data at rest and holding the keys in Azure Key Vault, authenticating users through Entra ID, locking down administrators with Database Vault, hardening the network around the delegated subnet, and evidencing all of it for compliance. Diagrams show how the Oracle and Azure control planes actually connect — because most security mistakes on this platform are boundary mistakes.
1.The Defense-in-Depth Model
No single control secures a database. Security is a stack of independent layers, each assuming the one outside it might fail. An attacker who slips past the network still meets authentication; one who steals a credential still meets Database Vault; one who reaches the storage still meets encryption. The goal is that no single failure is fatal.
On Oracle Database@Azure that stack is built from both vendors' tools, and the art is knowing which layer each tool belongs to.
The right mental model is not "Oracle security versus Azure security." It is one stack, assembled from both toolboxes, where each layer is owned by whichever vendor does that job best.
2.Who Secures What
Before configuring anything, be clear about the boundary. Misplacing a responsibility here is the root of most security gaps on the platform — a team assumes the other side is covering something, and nobody is.
| Responsibility | Owner |
|---|---|
| Physical datacenter security | Microsoft (facility) and Oracle (hardware) |
| Exadata firmware, hypervisor, storage-cell security patching | Oracle |
| Database software security patches | Oracle applies; you choose the window |
| Virtual network, NSGs, route tables, private endpoints | You |
| Entra ID users, groups, RBAC, Conditional Access | You |
| Database users, roles, privileges, Database Vault policy | You |
| TDE key lifecycle when using customer-managed keys | You |
| Audit policy, log review, incident response | You |
| Data classification and compliance evidence | You |
The pattern is consistent: Oracle keeps the platform secure and patched; everything about who reaches the data, how, and whether you can prove it, is yours. Encryption is on by default, but the moment you take control of the keys, their lifecycle becomes your responsibility too — a trade most regulated organisations accept willingly for the control it brings.
⚠️ The boundary trap
The most common security gap is not a misconfigured control — it is an unowned one. Because two clouds meet here, teams assume the other side handles key rotation, or audit review, or network rules. Write the responsibility matrix down, assign every row to a named team, and revisit it at every design review. An unowned control is an open door.
3.Encryption at Rest — TDE
Transparent Data Encryption is the innermost layer and the one you get for free: Oracle databases on this platform are encrypted with TDE by default. TDE encrypts datafiles, redo, and backups transparently — the application sees plaintext, the storage holds ciphertext, and anyone who steals the raw files gets nothing usable without the master key.
3.1 How the key hierarchy works
TDE uses a two-tier key model, and understanding it is the key to understanding everything about Azure Key Vault integration that follows.
3.2 Verifying the default encryption
Never assume — confirm. On any database on the platform, check that TDE is active and see where the master key currently lives.
-- Is the keystore open and is a master key set?
SELECT con_id, status, wallet_type, keystore_mode
FROM v$encryption_wallet;
-- Which tablespaces are encrypted, and with which algorithm?
SELECT tablespace_name, encrypted, ENCRYPTIONALG
FROM dba_tablespaces t
JOIN v$encrypted_tablespaces e USING (ts#) -- join on the tablespace id
WHERE encrypted = 'YES';
-- The current master key and where it is managed
SELECT key_id, creation_time, activation_time, key_use, keystore_type
FROM v$encryption_keys
ORDER BY creation_time DESC;Encryption is on — the decision is who holds the key
The data is already encrypted the moment the database exists; that part is not a project. The real security decision is where the master key lives and who controls its lifecycle. Leaving it in the Oracle-managed wallet is simplest; moving it to Azure Key Vault puts the key inside your own Azure security boundary. The next two sections are about making — and implementing — that choice.
4.Azure Key Vault Integration
This is the flagship security integration on the platform, and it answers a real enterprise need: organisations that standardise key management on Azure no longer have to make an exception for Oracle. TDE master keys can now be created, stored, and controlled in Azure Key Vault — across all three tiers (Standard, Premium, and Managed HSM, the last offering single-tenant, FIPS 140-3 Level 3 validated hardware) — so encryption keys sit inside your own Azure security boundary, managed with the same tools and policies as the rest of your estate.
4.1 How the connection actually works
The mechanism is worth understanding because it explains every prerequisite that follows. Each VM in the Exadata cluster is registered as an Azure Arc-enabled server, which gives it a managed identity in Microsoft Entra ID. That managed identity — not a stored credential — is what the database uses to reach the key vault. No password sits on disk; the cluster proves who it is through Azure's own identity fabric.
4.2 Prerequisites — get these right first
| Requirement | Detail |
|---|---|
| Azure roles | Owner or Contributor on the resource group to register Azure Arc machines |
| Entra ID permission | User Administrator to configure the identity access |
| Advanced networking | Must be enabled in the region — the integration installs an Oracle software library on the cluster VMs |
| Outbound connectivity | For Arc registration, through NAT Gateway, Azure Firewall, or an NVA |
| A key vault with a TDE key | Create the vault and a master key of a supported shape/size before you start |
| Private endpoint + split DNS | For zero-trust, private key traffic; needs split DNS on both the Azure and OCI sides |
4.3 Setting it up — the flow
The configuration spans both consoles. Here is the sequence, with the Azure-side commands.
STEP 1 Create the key vault and a TDE master key (Azure side).
# A Premium vault gives HSM-backed keys; use Managed HSM for FIPS 140-3 L3
az keyvault create \
--name kv-oradb-tde \
--resource-group rg-oracle-prod \
--location eastus \
--sku premium \
--enable-rbac-authorization true
# Create the TDE master key (RSA, HSM-backed)
az keyvault key create \
--vault-name kv-oradb-tde \
--name erpprod-tde-mek \
--kty RSA-HSM \
--size 2048STEP 2 Get an Azure access token and tenant ID for the Arc registration — the OCI console needs these to install the identity connector.
# Sign in as a user who can register Arc machines (Owner/Contributor on the RG)
az login
# The OCI console will ask for this token to authorize the Azure Arc install
export AZURE_TOKEN=$(az account get-access-token --query accessToken -o tsv)
# Note the tenant ID (a GUID); the OCI console requires it
export TENANT_ID=$(az account show --query tenantId -o tsv)
echo "Tenant: $TENANT_ID"STEP 3 In the OCI console, create the identity connector on the VM cluster (this registers each VM as an Arc server and grants the managed identity), then grant that identity access to the vault.
# After the OCI identity connector registers the VMs in Entra ID,
# grant the cluster's managed identity permission to use keys.
# With RBAC-authorized vaults, assign the crypto role:
az role assignment create \
--assignee <cluster-managed-identity-object-id> \
--role "Key Vault Crypto User" \
--scope $(az keyvault show --name kv-oradb-tde --query id -o tsv)STEP 4 In the OCI console, edit the database and switch key management from the Oracle wallet to the selected Azure Key Vault and key. Then confirm.
-- After switching, the keystore should report the external Azure-managed store
SELECT con_id, wallet_type, keystore_mode, status
FROM v$encryption_wallet;
-- And the active key should show it is managed externally
SELECT key_id, keystore_type, activation_time
FROM v$encryption_keys
ORDER BY activation_time DESC
FETCH FIRST 1 ROWS ONLY;
-- The definitive test: bounce the database. If it opens and the wallet
-- opens automatically, the identity + vault path is working end to end.⚠️ Rotate from the Oracle side — always
This is the single rule people get wrong. Even though the key lives in Azure Key Vault, you must perform TDE master-key rotation from the Oracle side — the OCI console or API — not directly in Azure. Rotating the key in Azure without going through Oracle leaves the database pointing at a version it does not know about, and it will fail to open the wallet. Use the Rotate control on the OCI database details page, and rotate on a schedule that matches your policy — commonly annual or event-driven.
What you gain, concretely
Keys sit inside your Azure security boundary. Lifecycle operations — creation, permissioning, policy, versioning — run through the Azure interface you already use, while rotation runs through Oracle without a database restart. You get unified auditing and monitoring of key operations alongside the rest of your Azure estate, and for the most stringent requirements, Managed HSM gives single-tenant, FIPS 140-3 Level 3 hardware. For a regulated organisation standardised on Azure, that consolidation is the whole point.
5.Choosing a Key Store
Azure Key Vault is not the only option, and it is not always the right one. Four choices exist, and the decision comes down to where you want control and how stringent your compliance bar is.
| Key store | Control model | Best for |
|---|---|---|
| Oracle Wallet (default) | File-based, on the database servers, Oracle-managed | Simplicity — no external dependency, fastest to stand up |
| OCI Vault | Customer-managed keys in OCI's managed KMS | Teams comfortable operating in OCI who want CMK without Azure |
| Oracle Key Vault (OKV) | Oracle's dedicated key-management appliance | Large Oracle estates centralising keys across many databases |
| Azure Key Vault | Customer-managed keys inside the Azure boundary | Organisations standardised on Azure governance and tooling |
The wallet is easiest; Azure Key Vault is most aligned with an Azure-standardised enterprise. The question is not which is most secure — all protect the key — but whose console and policies you want to manage it in.
🔧 A pragmatic default
If your organisation already manages secrets and keys in Azure Key Vault and answers to auditors in Azure's language, use AKV — the consolidation pays for the extra setup. If you are early, moving fast, or have no Azure key-management standard yet, start with the default wallet; you can switch an already-provisioned database to Azure Key Vault later without re-encrypting the data, because only the master key moves.
6.Microsoft Entra ID Authentication
Encryption protects data at rest; identity controls who gets in at all. The best practice on this platform is to centralise database authentication on Microsoft Entra ID, so database access is governed by the same directory, the same groups, and the same Conditional Access policies as everything else in the enterprise — rather than a separate island of database-local accounts.
6.1 Why centralise on Entra
Local database accounts are a governance problem: they live outside the corporate directory, they are easy to forget when someone leaves, and they carry their own password policies. Bringing authentication into Entra ID means a leaver disabled in the directory instantly loses database access, MFA and Conditional Access apply to database logins, and access reviews cover the database like any other resource.
| Concern | With local DB accounts | With Entra ID |
|---|---|---|
| Deprovisioning a leaver | Manual, per-database, easily missed | Disable once in the directory, access gone everywhere |
| MFA on database access | Not available natively | Enforced through Conditional Access |
| Access reviews / audit | Separate process per database | Part of standard Entra access reviews |
| Password policy | Database-local, inconsistent | Corporate policy, centrally enforced |
6.2 Mapping directory users to the database
Once the database is configured to trust Entra ID, you map schema-only database users to Entra users and groups. Group mapping is the pattern to prefer — you manage membership in the directory, not in every database.
-- Map a database user to an individual Entra ID principal
CREATE USER app_dba IDENTIFIED GLOBALLY AS
'AZURE_USER=jane.doe@contoso.com';
-- Better: map a shared schema to an Entra GROUP, manage membership in Entra
CREATE USER db_readers IDENTIFIED GLOBALLY AS
'AZURE_ROLE=Oracle_DB_Readers'; -- an Entra security group
GRANT CREATE SESSION TO db_readers;
GRANT SELECT ANY TABLE TO db_readers; -- scope this down in real systems
-- Anyone in the Entra group "Oracle_DB_Readers" now authenticates as db_readers.
-- Remove them from the group in Entra and their access disappears immediately.Prefer group mapping and shared schemas
Mapping Entra groups to database schemas — rather than one database user per person — keeps administration in the directory where it belongs. You add someone to the right Entra group and they gain access; you remove them and it is revoked, with no database change. Combined with Conditional Access requiring MFA and compliant devices, this turns database access into a governed, auditable part of your identity estate.
⚠️ Keep a break-glass local account
Do not make the database entirely dependent on external identity. Keep one tightly controlled, closely audited local account with the credentials in escrow, so an Entra ID outage or misconfiguration cannot lock every administrator out of the database at once. Test it, rotate it, and alert on its use.
7.Oracle Database Vault
Entra ID controls who logs in. Database Vault controls what even a privileged user can do once inside — and it closes the oldest gap in database security: the all-powerful DBA who can read every row in the database, including data they have no business seeing.
7.1 The problem it solves
By default, a user with DBA or SELECT ANY TABLE can read every table in the database. For a system holding regulated data — card numbers, health records, personal data — that is a compliance failure waiting to happen: the person who administers the database should not automatically be able to read its most sensitive contents. Database Vault enforces exactly that separation.
Realms
A protective boundary around a set of schemas or objects. Even a user with system privileges cannot access objects inside a realm unless they are explicitly authorised to that realm — so SELECT ANY TABLE stops meaning "read everything."
Command rules
Conditions attached to SQL commands — for example, block DROP TABLE on production schemas, or permit certain operations only from specific hosts or during change windows.
Separation of duties
Splits the omnipotent DBA into distinct roles: an account manager for users, a security admin for policy, and an operational DBA who runs the database without reading its protected data.
7.2 A realm in practice
Protect the finance schema so that operational DBAs can keep the database running but cannot read its contents.
-- Create a realm around the sensitive schema
BEGIN
DBMS_MACADM.CREATE_REALM(
realm_name => 'Finance Data Realm',
description => 'Protects FINANCE schema from privileged-user access',
enabled => DBMS_MACUTL.G_YES,
audit_options => DBMS_MACUTL.G_REALM_AUDIT_FAIL); -- audit access attempts
END;
/
-- Put the finance schema objects inside the realm
BEGIN
DBMS_MACADM.ADD_OBJECT_TO_REALM(
realm_name => 'Finance Data Realm',
object_owner => 'FINANCE',
object_name => '%', -- all objects
object_type => '%');
END;
/
-- Authorise ONLY the finance application account into the realm.
-- Note: a generic DBA is deliberately NOT authorised, so DBA power
-- no longer implies read access to FINANCE.
BEGIN
DBMS_MACADM.ADD_AUTH_TO_REALM(
realm_name => 'Finance Data Realm',
grantee => 'FIN_APP',
auth_options => DBMS_MACUTL.G_REALM_AUTH_OWNER);
END;
/-- Block destructive DDL on the finance schema outright
BEGIN
DBMS_MACADM.CREATE_COMMAND_RULE(
command => 'DROP TABLE',
rule_set_name => 'Disabled', -- a rule set that always evaluates false
object_owner => 'FINANCE',
object_name => '%',
enabled => DBMS_MACUTL.G_YES);
END;
/🔧 Where Database Vault fits the compliance story
Many regimes require demonstrable separation of duties and protection of regulated data from administrators. Database Vault is how you evidence that on Oracle: you can show an auditor that even holders of system privileges cannot read the protected schema, and that the control is enforced by the engine rather than by policy and good intentions. Turn it on before the data lands, not after an audit finding.
8.Network Security
The network is the outermost layer, and on this platform it centres on one thing: the delegated subnet where the database lives. Get the network right and the database is never exposed to the internet, reachable only from the paths you explicitly permit.
8.1 Principles for the delegated subnet
- Private by default. The database sits on a delegated subnet inside your own VNet, with private IPs. There is no reason for it to have a public endpoint — keep it off the internet entirely.
- Least-privilege NSGs. Network security group rules should permit only the listener port (1521, or 2484 for TCPS) from only the application subnets that genuinely need it. Deny everything else. The database subnet is not a general-purpose network.
- Private endpoints for dependencies. Key Vault, storage, and other services the database touches should be reached over private endpoints via Azure Private Link, not public endpoints — which is exactly why the AKV integration wants a private endpoint and split DNS.
- No NVA in the database hot path. For latency, application-to-database traffic should be direct, but that does not mean unprotected — the protection is the NSG and the private topology, not a firewall appliance inline with every query.
- Segment the tiers. Application, database, and management subnets should be separate, with controlled routing between them, so a compromise in one tier does not automatically reach the others.
8.2 A least-privilege NSG
# Allow the listener ONLY from the application subnet
az network nsg rule create \
--resource-group rg-oracle-prod \
--nsg-name nsg-oracle-db \
--name allow-sqlnet-from-app \
--priority 100 \
--direction Inbound --access Allow --protocol Tcp \
--source-address-prefixes 10.20.1.0/24 \
--destination-port-ranges 1521 2484 \
--description "SQL*Net from app subnet only"
# Explicitly deny all other inbound to the database subnet
az network nsg rule create \
--resource-group rg-oracle-prod \
--nsg-name nsg-oracle-db \
--name deny-all-inbound \
--priority 4096 \
--direction Inbound --access Deny --protocol '*' \
--source-address-prefixes '*' \
--destination-port-ranges '*' \
--description "Default deny"8.3 Encryption in transit
At-rest encryption is the default; in-transit encryption is your job to require. Configure native network encryption or, better, TLS (TCPS) so SQL*Net traffic between the application and the database is encrypted on the wire — even though it never leaves the datacenter, defense in depth assumes the internal network is not implicitly trusted.
# Require (not merely allow) native network encryption
SQLNET.ENCRYPTION_SERVER = REQUIRED
SQLNET.ENCRYPTION_TYPES_SERVER = (AES256)
SQLNET.CRYPTO_CHECKSUM_SERVER = REQUIRED
SQLNET.CRYPTO_CHECKSUM_TYPES_SERVER = (SHA256)
# For TLS, point at the wallet holding the certificates and use TCPS in tnsnames
WALLET_LOCATION =
(SOURCE = (METHOD = FILE)(METHOD_DATA = (DIRECTORY = /u01/app/oracle/wallet)))
SSL_VERSION = 1.2Zero trust, applied here
A zero-trust posture on this platform means: the database has no public endpoint; NSGs default-deny and permit only named source subnets; every service dependency is reached over a private endpoint; identity is verified through Entra ID on every connection; and traffic is encrypted in transit even inside the datacenter. None of these is exotic — together they mean a single breached layer does not hand over the data.
9.Auditing and Monitoring
Prevention fails silently; detection is what tells you. A serious security posture assumes some control will eventually be bypassed and ensures the attempt is recorded, surfaced, and actionable. This is also where the compliance story lives — an auditor wants evidence, and evidence is audit trail.
9.1 Unified auditing in the database
Use Oracle's unified audit trail with policies focused on what matters: privileged actions, access to sensitive schemas, and authentication events. Auditing everything drowns the signal; audit deliberately.
-- Audit all privileged and structural changes
CREATE AUDIT POLICY priv_actions_pol
ACTIONS CREATE USER, ALTER USER, DROP USER,
GRANT, REVOKE,
CREATE ROLE, ALTER ROLE, DROP ROLE,
ALTER SYSTEM, ALTER DATABASE;
AUDIT POLICY priv_actions_pol;
-- Audit any access to the sensitive finance schema
CREATE AUDIT POLICY finance_access_pol
ACTIONS SELECT, INSERT, UPDATE, DELETE ON FINANCE.ACCOUNTS,
SELECT, INSERT, UPDATE, DELETE ON FINANCE.LEDGER;
AUDIT POLICY finance_access_pol;
-- Audit every logon, successful or failed
CREATE AUDIT POLICY logon_pol ACTIONS LOGON;
AUDIT POLICY logon_pol;
-- Review recent failed logons and privileged actions
SELECT event_timestamp, dbusername, action_name, return_code
FROM unified_audit_trail
WHERE return_code <> 0
ORDER BY event_timestamp DESC
FETCH FIRST 50 ROWS ONLY;9.2 Push the signal into Azure
The audit trail is only useful if someone sees it. Surface database logs, metrics, and events in Azure Monitor, extend threat detection with Microsoft Defender, and correlate across the estate with Microsoft Sentinel — so a suspicious database event sits in the same SIEM as the rest of your security telemetry, not in an isolated corner nobody watches.
| Tool | Role in the security picture |
|---|---|
| Oracle Unified Audit | The authoritative in-database record of who did what |
| Azure Monitor | Central collection of logs, metrics, and events; alerting |
| Microsoft Defender | Threat detection, vulnerability findings, compliance posture |
| Microsoft Sentinel | SIEM correlation across database, app, network, and identity signals |
| Oracle Data Safe | Security assessment, user risk, sensitive-data discovery, activity auditing |
⚠️ An unread audit trail is theatre
Collecting audit data and never looking at it satisfies a checkbox and nothing else. Route the high-value events — failed privileged logons, realm-access denials, off-hours administrative actions — to alerts a human or an automated response will actually act on. The value is in the review and the response, not the collection.
10.SQL Firewall and Data Safe
Two more controls round out the Oracle-native side, both worth enabling on sensitive systems.
10.1 SQL Firewall — stopping injection at the engine
Oracle Database 23ai includes SQL Firewall, which runs inside the database kernel and enforces an allow-list of expected SQL for each user. Because it operates at the engine level, it sees every statement regardless of how it arrived — and it is one of the most effective defences against SQL injection, since an injected statement that is not on the allow-list is simply refused.
-- Enable SQL Firewall
EXEC DBMS_SQL_FIREWALL.ENABLE;
-- Capture the normal SQL and connection paths for an app user
BEGIN
DBMS_SQL_FIREWALL.CREATE_CAPTURE(
username => 'FIN_APP',
top_level_only => TRUE,
start_capture => TRUE);
END;
/
-- ... run a representative production workload to learn the allow-list ...
-- Stop capture, generate the allow-list, and enforce it
BEGIN
DBMS_SQL_FIREWALL.STOP_CAPTURE(username => 'FIN_APP');
DBMS_SQL_FIREWALL.GENERATE_ALLOW_LIST(username => 'FIN_APP');
DBMS_SQL_FIREWALL.ENABLE_ALLOW_LIST(
username => 'FIN_APP',
enforce => DBMS_SQL_FIREWALL.ENFORCE_ALL, -- SQL + connection path
block => TRUE,
audit => TRUE);
END;
/10.2 Oracle Data Safe — the assessment layer
Data Safe is a management service that continuously assesses the security posture: it flags configuration drift against best practice, discovers where sensitive data actually lives, evaluates user risk, and provides activity auditing. Registering the database with Data Safe gives you a running scorecard rather than a point-in-time review, which is exactly what a continuous-compliance programme needs.
Security assessment
Scores configuration against Oracle best practice and flags drift — missing audit policies, weak settings, excessive privileges.
Sensitive data discovery
Finds where regulated data lives across the schema, so you can protect what you actually have rather than what you think you have.
User risk assessment
Highlights over-privileged and dormant accounts — the ones most likely to be exploited or forgotten.
11.Compliance and Governance
Everything above exists, in part, to answer one question from an auditor: can you prove it? The platform's advantage for compliance is that the controls are enforced by the engine and the cloud fabric, and the evidence is generated automatically — you are demonstrating enforced reality, not documented intent.
| Compliance requirement | How you meet it here |
|---|---|
| Data encrypted at rest | TDE on by default; customer-managed keys in Azure Key Vault, up to FIPS 140-3 Level 3 HSM |
| Data encrypted in transit | Native network encryption or TLS required on SQL*Net |
| Separation of duties | Database Vault realms keep administrators out of protected data |
| Strong, centralised identity | Entra ID authentication with MFA and Conditional Access |
| Least-privilege access | Azure RBAC on resources, database roles and Vault realms on data |
| Auditable activity | Unified auditing exported to Azure Monitor and Sentinel |
| Continuous posture assessment | Oracle Data Safe plus Microsoft Defender |
| Data residency | Deploy in named in-region datacenters; keys and backups stay in-region |
| Key control and rotation evidence | Key lifecycle in Azure Key Vault; rotation performed and logged via Oracle |
Because provisioning runs through Azure Resource Manager, your existing Azure Policy definitions, RBAC assignments, resource locks, and activity-log audit trail apply to the Oracle estate automatically — so the governance you already evidence for the rest of Azure extends to these databases with no separate process.
Build the evidence in, from day one
The cheapest compliance programme is the one where evidence is a by-product of how the system runs, not a scramble before an audit. Turn on Database Vault, unified auditing, Data Safe, and Key Vault key management at build time; wire Azure Policy and Sentinel from the start. Then an audit becomes a matter of exporting what the platform already records — not reconstructing what happened after the fact.
12.A Hardening Checklist
A build-time checklist that turns the whole article into actions. Treat any unchecked item as a risk you have accepted deliberately, not one you forgot.
| Layer | Do this |
|---|---|
| Encryption | Confirm TDE is active; decide key store; move MEK to Azure Key Vault if standardised on Azure; require encryption in transit |
| Keys | Use Premium or Managed HSM for stringent needs; grant only the cluster identity; rotate from the Oracle side on a schedule |
| Identity | Authenticate via Entra ID; map groups not individuals; enforce MFA and Conditional Access; keep one audited break-glass account |
| Access control | Enable Database Vault; realm-protect sensitive schemas; separate DBA duties; block destructive DDL on production |
| Network | No public endpoint; default-deny NSGs allowing only app subnets; private endpoints for dependencies; segment tiers |
| Detection | Unified audit on privileged and sensitive actions; export to Azure Monitor and Sentinel; alert on the events that matter |
| Engine defences | Enable SQL Firewall on 23ai for sensitive app users; register with Data Safe for continuous assessment |
| Governance | Apply Azure Policy and RBAC; assign every responsibility-matrix row to a named owner; keep residency in-region |
| Operations | Apply Oracle security patches in your window; test the break-glass account; review audit and Data Safe findings on a cadence |
13.Frequently Asked Questions
Is my data encrypted by default?
Yes. Oracle databases on the platform use Transparent Data Encryption by default. What you decide is where the master key lives and who controls it — the Oracle wallet, OCI Vault, Oracle Key Vault, or Azure Key Vault.
Why move TDE keys to Azure Key Vault?
To keep encryption keys inside your own Azure security boundary and manage them with the same governance, auditing, and lifecycle tooling you use for the rest of your Azure estate. For organizations standardized on Azure, that consolidation is the main benefit; Managed HSM additionally offers FIPS 140-3 Level 3 hardware.
Can I rotate the TDE key from the Azure portal?
No — and this is the most common mistake. Even with the key in Azure Key Vault, rotate the TDE master key from the Oracle side (OCI console or API). Rotating directly in Azure leaves the database unable to open the wallet.
Does Database Vault stop the DBA reading sensitive data?
That is precisely its purpose. Realms wrap protected schemas so that even a user with system privileges cannot read them unless explicitly authorized — delivering the separation of duties most compliance regimes require.
How does Entra ID authentication help security?
It brings database logins under the corporate directory: MFA and Conditional Access apply, leavers lose access the moment they are disabled in Entra, and database access appears in standard access reviews. Prefer mapping Entra groups to shared schemas over per-person database accounts.
Is the database exposed to the internet?
It should not be. It lives on a private delegated subnet in your VNet with no public endpoint, reached only from the application subnets your NSGs explicitly permit, with dependencies accessed over private endpoints.
What do I need for a private, zero-trust key path?
A private endpoint for Azure Key Vault via Private Link, which requires advanced networking enabled in the region and split DNS configured on both the Azure and OCI sides. This keeps TDE key operations off the public internet entirely.
How do I prove compliance to an auditor?
Show enforced controls and their generated evidence: TDE and key management in Key Vault, Database Vault separation of duties, Entra ID with MFA, unified audit exported to Sentinel, and Data Safe assessments — plus the Azure Policy and RBAC applied through Resource Manager. The evidence is a by-product of running the system, not a separate exercise.
14.Key Takeaways
The short version
• Security is one layered stack from two toolboxes. Use each vendor where it is strongest — Azure for identity, keys, network, and monitoring; Oracle for encryption, Database Vault, SQL Firewall, and Data Safe.
• Encryption is free; key control is the decision. TDE is on by default — the real choice is holding the master key in Azure Key Vault inside your own boundary, and rotating it from the Oracle side.
• Centralise identity on Entra ID. Map groups to schemas, enforce MFA and Conditional Access, and keep one audited break-glass account.
• Database Vault closes the privileged-user gap — the separation of duties that keeps administrators out of regulated data and satisfies auditors.
• Assume a layer will fail. Default-deny the network, audit the high-value events, push them into Sentinel, and act on what you see.
• Own the boundary. The biggest risk is an unowned control — assign every responsibility to a named team and build the compliance evidence in from day one.
The security model for Oracle Database@Azure is not harder than a single-cloud database — it is different, because two vendors' controls meet at the data. The organisations that do it well stop thinking about "Oracle security" and "Azure security" as separate problems and start treating them as one layered stack: identity and keys and network and monitoring from Azure, encryption and access control and engine-level defences from Oracle, each doing the job it does best.
Do that, wire the evidence in from the start, and the platform becomes not a compliance liability but one of the easier parts of the estate to defend — because for once, the crown-jewel data and the tools to protect it live in the same place.
Security features, integration steps, supported key-vault tiers, and compliance capabilities reflect Oracle and Microsoft documentation available at the time of writing and change frequently — verify current details, prerequisites, and supported configurations against Oracle and Microsoft sources before implementing. All commands and configuration are illustrative, use placeholder values, and must be validated against your own versions and current documentation before use. This article is independent commentary and is not affiliated with, endorsed by, or sponsored by Oracle or Microsoft.
Comments