Oracle Autonomous Database Security Guide

Oracle Autonomous AI Database Serverless takes patching and infrastructure off your plate, but who can reach the database, how clients authenticate and who holds the encryption keys remain settings you choose. This guide covers the customer side of the shared responsibility model: the three network access options, mutual TLS and wallets, OCI IAM authentication for database users, the ADMIN account, customer managed master encryption keys, auditing and Oracle Data Safe. It is written for DBAs, cloud platform engineers and security architects who run Autonomous Database in production. Database engine controls that apply to every Oracle deployment, such as privilege analysis and Virtual Private Database, are covered in the Oracle Database Security Guide, and tenancy wide controls in the Oracle Cloud Infrastructure Security Guide.

This is an independent guide from NHI Mgmt Group, based on Oracle's public documentation as of November 2026. It is not sponsored or reviewed by Oracle. Product features change, so confirm settings against Oracle's current documentation.

Key takeaways

Choose the network option before anything else. New databases default to "Secure access from everywhere"; move production to ACL restricted access or "Private endpoint access only", and add NSG rules on ports 1522 (mTLS) and 1521 or 1522 (TLS).
Keep mutual TLS required unless you have a reason. TLS without a wallet is only allowed once ACLs or a private endpoint are in place, and only some client drivers can use it.
Treat wallets as credentials. Download instance wallets rather than regional ones, store them in a secrets manager and rotate with a 1 to 72 hour grace period on a schedule or on suspicion of exposure.
Move people to OCI IAM authentication. Enable it with DBMS_CLOUD_ADMIN.ENABLE_EXTERNAL_AUTHENTICATION and map IAM groups to global roles, so joiners and leavers are handled in one place.
Extend audit retention beyond 14 days. The default unified audit trail is purged after 14 days; register the database with Data Safe and start an audit trail to keep months of history.

How identity and access work in Autonomous Database

Access to an Autonomous Database has two planes. The control plane is OCI: IAM policies on the autonomous-database-family resource type decide who can create, stop, clone, rotate wallets or change network settings. The data plane is the database itself: a SQL session needs a network path, a TLS handshake and a database identity with privileges. A secure deployment controls all three layers of the data plane, not only the password.

Layer	What decides access	Customer controls
OCI control plane	IAM policies, compartments	Who can manage the database, its network access, wallets and keys
Network path	Network access option, ACLs, NSGs, Security Lists	Public endpoint with ACLs, or private endpoint in your VCN
Transport	mTLS (wallet) or TLS	"Require mutual TLS (mTLS) authentication" setting, wallet rotation
Database identity	Local users, OCI IAM global users and roles	Authentication scheme, role design, ADMIN usage
Data at rest	TDE master key	Oracle managed or customer managed key

Network access options

Oracle documents three options, chosen at provisioning or clone time and changeable later:

Secure access from everywhere: a public endpoint reachable from all IP addresses. This is the default. You can still add ACLs after provisioning.
Secure access from allowed IPs and VCNs only: a public endpoint that accepts connections only from the IP addresses, CIDR blocks and VCNs in the access control list. Once an ACL is set, everything else is blocked.
Private endpoint access only: a private IP and hostname inside a VCN you choose, with public access blocked. Traffic is filtered by up to five Network Security Groups and the subnet Security Lists.

For private endpoints, add stateful TCP ingress rules: destination port 1522 for mTLS, 1521 or 1522 for TLS, and 443 if users reach Database Actions, APEX or ORDS. On ECPU databases you can also enable "Allow public access" alongside a private endpoint, scoped to specific IP addresses, CIDR blocks or a VCN reached through a Service Gateway; use it only where a named consumer needs it. When you switch an existing database from public to private, every user must download a new wallet, and existing public ACLs do not carry over to the private endpoint. See the Network Segmentation Guide for the wider design.

Mutual TLS, TLS and wallets

All connections are encrypted. The question is whether the client must also present a certificate. With Require mutual TLS (mTLS) authentication selected, the Network area shows "Required" and only wallet based mTLS connections succeed. Deselecting it allows both TLS and mTLS, but only when ACLs are enabled or the access type is a VCN private endpoint; on "Secure access from everywhere" TLS is only possible after you add ACLs. JDBC Thin and managed ODP.NET or ODP.NET Core 19.13 or 21.4 and later can use TLS without a wallet; SQL*Plus, OCI, ODBC and JDBC OCI clients still need the CA certificate in a wallet. Turning mTLS back on disconnects existing TLS sessions, so plan the change.

Keep SSL_SERVER_DN_MATCH=YES in client configuration: Oracle recommends it because setting it to NO turns off hostname validation and opens the door to interception. For the protocol background see the mTLS Guide.

Wallet type	Scope	Use
Instance wallet	One database	Default for applications and users; Oracle recommends it
Regional wallet	Every Autonomous Database for the tenant in the region	Only where one wallet must reach several databases, for example a central monitoring host

Rotation can be immediate or after a grace period of 1 to 72 hours. Immediate rotation voids old instance wallets for that database at once; rotating the regional wallet voids both regional and instance wallets across the region. Existing sessions are not cut instantly, so restart the instance if you need every old connection gone. Always Free databases support only immediate rotation. Rotation is also available through the UpdateAutonomousDatabaseWallet and UpdateAutonomousDatabaseRegionalWallet API operations, which lets you schedule it.

Admin roles and privileged access

Every Autonomous Database has an ADMIN user, and ADMIN holds AUDIT_ADMIN by default. That makes it the account that can enable external authentication, create users and purge audit records. Treat it as a break glass identity:

Vault the ADMIN password: store it in OCI Vault or your PAM tool, restrict who can retrieve it and alert on retrieval. See the Secrets Management Guide.
Create named administrators: give DBAs their own accounts or IAM global roles with only the privileges they need, so audit records name a person.
Separate audit duties: limit AUDIT_ADMIN to a small group, because it carries the right to purge the unified audit trail.
Control the control plane: write IAM policies so that only the platform team can manage the database family resources in production compartments, and give application teams narrower verbs. Changing network access, rotating wallets and managing encryption keys are all control plane actions.
Review privileges regularly: run Data Safe User Assessment, which runs weekly and flags the riskiest accounts; set a User Assessment baseline so new accounts or privilege changes raise an OCI Events notification.

OCI IAM authentication for database users

Autonomous Database can authenticate users against OCI IAM, including identity domains and non-default domains. Only one external authentication scheme can be active at a time. As ADMIN, run DBMS_CLOUD_ADMIN.ENABLE_EXTERNAL_AUTHENTICATION(type => 'OCI_IAM'); if another scheme is already active the call fails with ORA-20004 unless you pass force => TRUE. Confirm with a query on V$PARAMETER for identity_provider_type, which should read OCI_IAM.

Then map IAM groups to database roles with CREATE ROLE ... IDENTIFIED GLOBALLY AS 'IAM_GROUP_NAME=GroupName' (prefix the domain for non-default domains, for example sales_domain/ExporterGroup) and grant the role its privileges. Oracle describes two models: exclusive mapping, one IAM user to one schema, and shared mapping, many IAM users to one shared schema with global roles adding privileges per group. Shared mapping keeps schema sprawl down; exclusive mapping gives cleaner per person accountability. Users sign in with an IAM database password they create in IAM, and OCI applications can connect using instance and resource principals rather than stored passwords. The result is that a leaver removed from an IAM group loses database access without a separate DBA ticket.

Integrations, API tokens and service accounts

Most connections to a production Autonomous Database are not people: they are application pools, ETL jobs, BI tools and scripts. Each is a non-human identity with three secrets to look after: the wallet, the database password and any cloud credential the database itself uses to reach object storage.

One schema per workload: give each application or pipeline its own database user with only the grants it needs, never a shared ADMIN connection.
Prefer principals over stored passwords: where the client runs on OCI, use instance or resource principals with IAM authentication so there is no long lived password to leak.
Store wallets and passwords in a vault: fetch them at start up, never commit them to repositories or bake them into container images. See the NHI Authentication Guide for workload credential options.
Route database egress through your VCN: on a private endpoint, set ALTER DATABASE PROPERTY SET ROUTE_OUTBOUND_CONNECTIONS = 'ENFORCE_PRIVATE_ENDPOINT', the value Oracle recommends. It sends UTL_HTTP, UTL_SMTP, database links, external tables, Data Pump and the DBMS_CLOUD family through your private endpoint, so your NSG egress rules govern them. When the property is unset, outbound calls to public hosts leave through the service NAT gateway and bypass your egress rules. It applies only to database links created after it is set.
Review data movement paths: pipelines that read from Autonomous Database follow the controls in the ETL and ELT Pipeline Security Guide.

Customer managed master encryption keys

By default Oracle creates and rotates the TDE master key. You can instead have the TDE master key generated from a key in OCI Vault, Microsoft Azure Key Vault, AWS Key Management Service or Oracle Key Vault, set at provisioning, cloning or later through Manage Encryption Key. Keys in a remote tenancy are supported if the vault and database are in the same region. Know the operational consequences before you choose it:

Event	Documented effect	What to do
Key disabled or deleted	Database becomes Inaccessible within about 15 minutes; re-enabling a disabled key returns it to Available	Restrict key disable and delete rights to a separate key custodian group
Key provider unreachable	Database keeps running for a 2 hour grace period, then becomes Inaccessible; a stopped database cannot start	Monitor vault health and include it in incident runbooks
Key rotation	Use a key not used for rotation in the last 60 days	Keep at least one prior key available so backups stay restorable
Restore or clone from backup	Needs the key that was active at backup time; key history lists names and activation times	Never delete keys inside your backup retention window
Autonomous Data Guard	Only OCI Vault is supported; a cross-region standby needs the key replicated to that region	Replicate the key before adding a cross-region standby

For the trade-offs between provider held and customer held keys, see the BYOK, HYOK and External Key Management Guide.

Logging and detection

Autonomous Database writes default auditing to the UNIFIED_AUDIT_TRAIL view, backed by the protected AUDSYS.AUD$UNIFIED table: DML, DDL and purges against it are blocked and themselves audited. Default policies capture all activity by Oracle Cloud Operations, all failed logins, all password changes, attempts to create or alter procedures and execution of network packages such as UTL_HTTP and UTL_SMTP. A daily job purges records older than 14 days.

To keep longer history and build alerts, register the database with Oracle Data Safe from the Details page (status moves from Registering to Registered in about 15 to 20 minutes; a private endpoint database also needs a Data Safe private endpoint) and start an audit trail. Activity Auditing then collects records, applies predefined or custom audit policies, produces reports and raises alerts. Oracle includes 1 million audit records per database per month for Autonomous Database. If the database restarts, the trail shows RETRYING for up to four hours and then STOPPED_NEEDS_ATTN, which needs a manual resume: alert on that state, or your history will have gaps. For detection content built on these records, see the Database Audit Log Detection Guide.

Signal	Source	Why it matters
Failed logins by user and client IP	Unified audit trail, Data Safe	Password guessing or a stale credential in a pipeline
Changes to network access, mTLS setting or ACLs	OCI Audit (control plane)	Exposure of a private database
Wallet rotation or download	OCI Audit	Credential issuance outside change windows
Encryption key state changes	OCI Vault and OCI Audit	Imminent loss of availability
New users, grants and role changes	Unified audit trail, User Assessment baseline	Privilege creep and persistence
Audit trail state STOPPED_NEEDS_ATTN	Data Safe	Silent gap in evidence

Metrics to track: share of production databases on private endpoints or ACLs; share with mTLS required; days since last wallet rotation per database; percentage of human users authenticating through IAM rather than local passwords; Data Safe Security Assessment high risk findings open over 30 days; audit trail uptime.

Hardening baseline

Network: provision production with "Private endpoint access only", or ACLs listing named IP ranges and VCNs. Attach NSGs that open only 1522 (and 1521 or 443 where required) from application subnets.
Egress: set ROUTE_OUTBOUND_CONNECTIONS to ENFORCE_PRIVATE_ENDPOINT and define NSG egress rules for the hosts the database may call.
Transport: keep mTLS required unless a supported thin driver needs TLS; keep SSL_SERVER_DN_MATCH=YES.
Wallets: issue instance wallets only, store them in a vault, rotate on a schedule with a grace period and immediately on suspected exposure.
Identity: enable OCI IAM authentication, map IAM groups to global roles, vault the ADMIN password and stop using ADMIN for routine work.
Keys: decide on Oracle managed or customer managed keys per data classification; for customer managed keys, separate key custodians from DBAs and keep 60 days of rotation history.
Assessment: register with Data Safe, review weekly Security Assessment and User Assessment results, set baselines and run Data Discovery to find sensitive columns; use Data Masking before copying production data to test.
Audit: start a Data Safe audit trail, set retention to match your policy and forward alerts to your SIEM.

Testing and rollback: change network access or mTLS on a clone or non-production database first, because a network change forces new wallets and enabling mTLS drops TLS sessions. Use the wallet grace period as your rollback window. Every network access option can be changed again after provisioning, so a failed private endpoint cut-over can be reverted while you fix DNS.

Common misconfigurations

Leaving the default open endpoint: production databases stay on "Secure access from everywhere" with no ACL because the proof of concept never moved. Add ACLs or a private endpoint before go-live.
Private endpoint, public egress: the database sits in a VCN but ROUTE_OUTBOUND_CONNECTIONS is unset, so DBMS_CLOUD calls and database links leave through the service NAT gateway outside your egress rules.
Regional wallets on application hosts: a wallet that reaches every database in the region is copied to one application server. Issue instance wallets per workload.
Wallets in source control: wallet zip files and passwords committed with application code. Keep them in a secrets manager and rotate when a repository is exposed.
Customer managed key without custody rules: a DBA who can disable the vault key can take the database offline. Split duties and alert on key state changes.
Relying on the 14 day trail: an investigation reaches back further than the default purge window. Data Safe retention closes that gap.

Framework mapping

Control area	Autonomous Database setting	NIST SP 800-53 Rev 5	NIST CSF 2.0
Network boundary	Private endpoint, ACLs, NSGs	SC-7	PR.PS-01
Data in transit	mTLS, SSL_SERVER_DN_MATCH	SC-8	PR.DS-02
Authenticators	Wallet rotation, ADMIN password vaulting	IA-5	PR.AA-01
User identity and accounts	OCI IAM authentication, global roles	IA-2, AC-2	PR.AA-01
Least privilege	Role design, User Assessment	AC-6	PR.AA-05
Data at rest and keys	TDE with customer managed keys	SC-28, SC-12	PR.DS-01
Audit and retention	Unified auditing, Data Safe Activity Auditing	AU-2, AU-6, AU-11	DE.CM-09

Practitioner checklist

Inventory every Autonomous Database and record its network access option, ACLs and mTLS setting.
Move production databases to a private endpoint or ACL restricted public endpoint, with NSGs limited to required ports.
Set ROUTE_OUTBOUND_CONNECTIONS to ENFORCE_PRIVATE_ENDPOINT on private endpoint databases.
Replace regional wallets with instance wallets, store them in a vault and schedule grace period rotation.
Enable OCI IAM authentication and map IAM groups to global roles; vault the ADMIN password.
Give each application and pipeline its own schema and, on OCI, use resource or instance principals.
Decide key ownership per data class; for customer managed keys, separate custodians and keep 60 days of key history.
Register with Data Safe, start the audit trail, extend retention and alert on STOPPED_NEEDS_ATTN.
Review weekly Security Assessment and User Assessment results and act on drift from baseline.

Oracle Autonomous Database Security: Wallets, Network Access, IAM Auth and Keys Configured Well