Security Management Improvements in Oracle AI Database 26ai

Security management determines who may connect, which data they may access, how that data is protected, and what evidence is retained. Oracle AI Database 26ai provides capabilities that help administrators manage these responsibilities, including schema privileges, SQL Firewall, newer authentication and encryption options, and release-specific Deep Data Security features. Effective protection still requires correctly configured policies and verification.

Consider an application that maintains employee records. Its object owner, runtime service account, reporting account, security administrator, and audit reviewer have different jobs. Giving all of them the same powerful role would erase those boundaries. A useful security design starts by identifying the operations each identity actually needs.

Oracle 19c and 21c already supported database-enforced controls such as privileges, roles, Virtual Private Database, and Unified Auditing. The improvements discussed here build on that foundation. Some capabilities were carried forward from the 23c/23ai release family; others depend on a particular release update (RU). Always check the installed RU, cloud service, client compatibility, and feature entitlement before planning implementation.

Six Areas of Security Management

The previous lesson explained cloud connection paths. A private endpoint narrows network exposure, but it does not decide whether a reporting account can update salaries. Likewise, encrypted storage does not stop an authorized session from reading plaintext results. Each area in the diagram addresses a different part of the problem.

Identify Users and Separate Responsibilities

Authentication establishes an identity; authorization determines its allowed operations. Oracle Cloud Infrastructure Identity and Access Management (OCI IAM) policies governing cloud resources are distinct from database privileges. A user who can manage a cloud resource does not automatically receive every SQL privilege inside its database.

For the employee application, use separate identities for object ownership, application execution, reporting, and administration. Schema-only accounts can own objects without direct authentication. This technique was already documented in Oracle 19c; it should not be treated as newly introduced in 26ai. The runtime account receives only the access needed by the application.

Manage credentials throughout their lifecycle: approve account creation, configure applicable password profiles, protect secrets, review unused access, and revoke credentials when their purpose ends. A shared application login also needs a trustworthy way to distinguish its end users. Otherwise, database records may identify the service account without adequately explaining which person initiated an operation.

Oracle's 26ai security release notes document native database-user multifactor authentication from RU 23.9. Verify the supported authentication method and clients before enabling it. Do not assume that every feature comparison can be based solely on the major version, because older releases may receive backports. The documented password maximum is now 1024 bytes, which is a limit rather than a recommended password length; bytes and characters are not interchangeable.

Use Schema Privileges Where Their Scope Fits

A reporting role sometimes needs access throughout one schema. Granting database-wide SELECT ANY TABLE is broader than that requirement, while repeatedly granting access to individual objects can become difficult to maintain. Schema privileges provide an intermediate scope.

Assume that HR and REPORTING_ROLE already exist in the intended pluggable database (PDB). An authorized grantor can use:

GRANT SELECT ANY TABLE ON SCHEMA HR TO REPORTING_ROLE;

This schema-scoped grant covers applicable objects in HR, including future objects, rather than granting the privilege throughout the database. It does not create the role, assign it to a user, or grant CREATE SESSION. It also does not remove unrelated privileges the recipient already holds.

The scope may still be too broad. If HR contains both public staff-directory information and confidential compensation data, a reporting account may need selected views or individual object grants instead. Review future-object exposure before choosing a schema privilege. Permission to select data is not a guarantee that the entire session is read-only.

The predefined DB_DEVELOPER_ROLE can simplify development access, but it should be reviewed against the developer's actual tasks. A development role is not automatically an appropriate production runtime role. Check both direct grants and inherited role access when verifying the final privilege set.

Control SQL Workloads with SQL Firewall

Oracle SQL Firewall operates inside the database to restrict SQL and connection contexts for designated users. It can log or block activity that falls outside the configured allow-list. This adds a workload control beyond deciding whether a client can reach a listener or authenticate successfully.

For the application's service account, establish a representative baseline before enforcing restrictions. Include normal online requests and scheduled work, such as monthly reporting and approved maintenance operations. A baseline built from only a brief demonstration may omit legitimate activity and cause avoidable production failures.

1. Capture: collect representative, trusted application activity.
2. Review: determine whether the captured statements and connection contexts are appropriate.
3. Generate and monitor: create the allow-list and investigate unexpected activity.
4. Enforce: introduce blocking under change control and verify application behavior.
5. Maintain: review changes before deploying new application operations.

This follows Oracle's SQL Firewall management sequence. A violation can reflect an attack, a configuration problem, or legitimate new functionality. Investigate the context rather than treating every event as proof of intrusion.

SQL Firewall complements parameterized application SQL and access-control policies. It does not decide which employee rows a manager should see. Dynamic reporting and AI-generated queries also require a suitable workload policy; enabling the feature does not automatically authorize every safe query or recognize every unsafe one. Confirm entitlement and deployment support before implementation.

Enforce Data Authorization for Applications and Agents

Object permissions answer whether a principal may access an object. Fine-grained authorization can further restrict which records or fields are available. For example, a department manager may need employee details only for that department, while payroll staff require a different view of the same underlying information.

Oracle Deep Data Security provides declarative, database-enforced authorization using end-user roles and attributes, with row, column, and cell-level control. Oracle lists the feature under RU 23.26.2. Its 23.26.3 enhancements include application-identity logon and MFA for database-managed end users. These end-user capabilities have a separate release history from native database-account MFA.

The application must establish trustworthy user context and the administrator must configure the required policies. An AI agent does not automatically inherit a person's restrictions simply because the database runs 26ai. Test access through the actual application or agent path, including attempts to retrieve data outside that person's scope.

Virtual Private Database (VPD) and Real Application Security already provided database-enforced controls in earlier releases. Evaluate new capabilities against the application's requirements and existing policies. With pooled connections, verify that one user's context cannot persist into another user's request. Test at least two users with different entitlements, including permitted reads and deliberately denied access.

Protect Data in Transit, at Rest, and in Backups

Transport Layer Security (TLS) 1.3 is supported in 26ai, but the actual connection depends on compatible clients and configuration. Oracle native network encryption is a different mechanism. A private subnet or FastConnect connection does not automatically configure TLS or validate the database server's certificate.

Transparent Data Encryption (TDE) protects stored data while allowing authorized database operations to use decrypted values. Consequently, an account with excessive read privileges remains a risk even when storage encryption is enabled. Encryption and least privilege must be designed together.

Distinguish TDE keystores, TLS certificate wallets, and wallets holding connection credentials by their purpose. Document who can administer keys, where recovery copies are held, and how a restored database obtains the required historical keys. Rotation must be accompanied by a recovery plan. A backup that cannot be decrypted when needed does not meet the recovery objective.

Oracle also documents ML-KEM and hybrid key exchange for TLS. These capabilities depend on compatible implementations and settings. They do not make every existing connection or backup quantum-resistant after an upgrade. Follow the TLS configuration guidance for the deployed clients and server.

Define, Enable, and Verify Unified Auditing

Traditional auditing is desupported in Oracle AI Database 26ai. Use Unified Auditing to configure the required evidence. Separate policy administration through AUDIT_ADMIN from review through AUDIT_VIEWER, subject to the deployment's additional security controls.

The following example defines and enables an update policy. It assumes that HR.EMPLOYEES and APP_USER already exist in a nonproduction PDB and that the policy name is unused. Run the administrative statements with appropriate audit-policy authority. These documentation-based examples have not been executed against a live database.

CREATE AUDIT POLICY lesson6_employee_updates
  ACTIONS UPDATE ON HR.EMPLOYEES;

AUDIT POLICY lesson6_employee_updates BY APP_USER;

Creating the policy defines its scope; enabling it activates the specified auditing. Neither statement grants UPDATE permission to APP_USER. Confirm enablement using an authorized audit account:

SELECT policy_name, enabled_option, entity_name
FROM audit_unified_enabled_policies
WHERE policy_name = 'LESSON6_EMPLOYEE_UPDATES';

In the test environment, perform an approved UPDATE as APP_USER using disposable test data and separately granted privileges. Then inspect the resulting evidence with an account permitted to read the audit trail:

SELECT event_timestamp, dbusername, action_name,
       object_schema, object_name, return_code,
       unified_audit_policies
FROM unified_audit_trail
WHERE dbusername = 'APP_USER'
  AND object_schema = 'HR'
  AND object_name = 'EMPLOYEES'
  AND action_name = 'UPDATE'
  AND event_timestamp >= LOCALTIMESTAMP - INTERVAL '1' HOUR
ORDER BY event_timestamp DESC;

Check the event time and listed policies against the test operation. A zero return code indicates a successful statement; it does not prove that the transaction was committed. A nonzero code needs investigation. If evidence is missing, check the PDB, user, policy enablement, and actual operation before concluding that auditing has failed.

After completing this isolated demonstration, the audit administrator can remove its configuration:

NOAUDIT POLICY lesson6_employee_updates BY APP_USER;
DROP AUDIT POLICY lesson6_employee_updates;

Removing the policy does not erase existing audit records. Manage retention and purging through the approved audit-management process. Protect access to the records, establish a review owner, and plan capacity for the event volume rather than collecting evidence without a review procedure.

Maintain the Controls as the Application Changes

Managed cloud services can automate infrastructure and maintenance tasks, but customers still decide application privileges, data access, and acceptable exposure. Do not assume that all maintenance is interruption-free, every export is encrypted, or copied production data is automatically masked. Verify the behavior of the service and operation you actually use.

Before an application release, review new objects, schema-wide grants, SQL Firewall baselines, user-context handling, and audit coverage. A new sensitive table may be immediately accessible through an existing schema privilege. A new application operation may need a reviewed workload-policy change. Treat these as release decisions rather than emergency fixes after deployment.

Record security exceptions with an owner and review date. Include client compatibility in patch planning, and test recovery with the required key material. A control remains useful only when its configuration matches the current application and someone is responsible for investigating unexpected behavior.

Compare the Management Tasks with 19c and 21c

This comparison describes areas to evaluate, not a feature-certification matrix. Installed updates and cloud-service capabilities can change what an older release supports. Compare the actual environments and operational requirements before deciding which configuration to adopt.

Security Review Checklist

• Identify the database release update, service model, and supported security features.
• Separate owners, runtime users, administrators, and audit reviewers.
• Review direct grants, inherited roles, and exposure of future schema objects.
• Test end-user data policies through real application and pooled-session paths.
• Capture and maintain approved SQL workloads before enforcing restrictions.
• Verify transport encryption, stored-data protection, and recoverable keys.
• Enable audit policies, generate test events, and inspect the resulting records.
• Recheck allowed and denied operations after application or security changes.

The management improvement comes from applying each capability to a defined requirement and verifying the result. Oracle 26ai provides additional tools for that work, while established practices such as least privilege, separation of duties, and protected audit review remain essential.