OCI Data Safe, in depth: connecting targets, assessments and drift, discovery and masking, audit collection and retention, alerts and SQL Firewall

How Data Safe reaches your databases

Each database you protect becomes a target database in a compartment. Data Safe needs a network path and a database account on every target. The path depends on where the database lives. Autonomous databases register directly. Databases in your VCN, such as Base Database systems and Exadata, are reached through a Data Safe private endpoint, a virtual network interface placed in a subnet you choose; your security lists or network security groups must allow it to reach the listener port. On-premises and other-cloud databases are reached through an on-premises connector, software you install on a host near the database that opens an outbound connection to Data Safe, so no inbound firewall hole is needed. Traffic uses either TCP with Oracle native network encryption enabled on the database or TCPS with TLS 1.2.

The database account is the second half. Autonomous databases ship with a Data Safe service account. For other databases you create a user and run the privileges script that the registration wizard provides; it grants Data Safe roles such as ASSESSMENT, AUDIT_COLLECTION, AUDIT_SETTING and DATA_DISCOVERY. The features that work on a target are exactly those whose roles you granted, which makes least privilege easy: a team that only wants assessments and audit collection grants only those.

Access control and registration

Access to Data Safe itself is controlled by OCI IAM. The broad resource family is data-safe-family, and narrower families exist per feature, which lets you separate the people who run masking from the people who read audit data.

Allow group DataSafeAdmins to manage data-safe-family in compartment security
Allow group AuditReviewers to read data-safe-audit-family in compartment security
Allow group TestDataEngineers to manage data-safe-masking-family in compartment nonprod

Registering a cloud database also needs permissions on the database resource and, for private endpoints, on the network, because Data Safe creates resources there on your behalf. The registration wizard tells you which are missing. Plan compartments before registering: targets, assessments, sensitive data models and audit trails all live in compartments, and IAM policies follow them. A common layout puts Data Safe resources in a dedicated security compartment that database teams can read but not delete. For how compartments and policy inheritance work, see OCI IAM.

A registration is complete when the target shows as active and a first security assessment runs. Do that immediately: it proves the network path, the credentials and the granted roles in one step.

Security and user assessments

Security Assessment reads the database's configuration and reports findings grouped by risk: patch level, encryption settings, auditing configuration, risky parameters, privilege grants and more. Findings are mapped to references including the CIS benchmark, DISA STIG, the EU GDPR and Oracle's own best practices, which is useful when an auditor asks which control a finding relates to.

User Assessment looks at accounts: which users hold powerful system privileges or roles, which use password authentication and when they last changed a password, which accounts are dormant, and which have access to which schemas. The most common real finding is not an attacker but drift: an application account that was granted DBA during an incident and never cleaned up.

Both features become useful when you stop reading individual reports and start comparing. Set a reviewed assessment as the baseline, schedule the assessment to run regularly, and let Data Safe report differences against the baseline. A new finding or a new privileged user then shows up as a change you can route to a ticket, instead of one line among two hundred. Fixes are yours to apply in the database; Data Safe re-measures on the next run.

Finding sensitive data

Data Discovery scans schemas for columns that look like sensitive data, using predefined sensitive types grouped into categories such as identification, biographic, IT, financial, healthcare, employment and academic data, plus custom types you define by column-name and data patterns. The result is a sensitive data model: a list of sensitive columns and, importantly, the referential relationships between them, discovered from database constraints or added by you.

Treat discovery output as a draft. Pattern matching misses columns with meaningless names such as ATTR7 and flags harmless ones, so a data owner should review the model before anything depends on it. The reviewed model then drives three things: masking policies, audit policies that watch access to sensitive columns, and conversations about whether that data needs to be in this database at all.

Masking non-production copies

Data Masking replaces sensitive values in a copy of a database so developers and testers can work with realistic data. You generate a masking policy from a sensitive data model, choose a masking format per column, such as shuffling values within the column, generating random replacements or producing format-preserving email addresses, and run the policy against a non-production target.

Two properties drive how you operate it. Masking is irreversible on the target, which is the point, so never point a masking job at production; enforce this with IAM by granting data-safe-masking-family only in non-production compartments. And masking preserves relationships only for columns the model knows are related; if a customer id appears in two tables without a declared constraint, add the relationship to the model, or joins in the masked copy will break. Run masking as a step in the clone pipeline, after the copy and before any person gets access, and verify by sampling that no original values survive.

Activity auditing, retention and cost

Activity Auditing has two halves. On the database side, Data Safe can provision audit policies, such as the predefined policies for administrative and user activity, policies aligned with CIS and STIG and your own custom unified audit policies. On the collection side, an audit trail per target pulls records from the database's audit trail into Data Safe, where you report on them, filter them and keep them after the database has purged its local copy.

Retention is set in an audit profile: online retention from 1 to 12 months, where records are searchable in reports, and offline archive retention from 0 to 72 months, for a maximum of seven years from the time the record was generated. Cost is driven by volume. Oracle's published terms give cloud database subscribers 1 million collected audit records per target database per month free; collection beyond that requires enabling paid usage in the audit profile, and is charged per record. Without paid usage, collection stops at the free limit for the month, which can leave a gap in exactly the month you need the data.

Volume is a design decision, not an accident. A policy that audits every SELECT by the application account can generate tens of millions of records a day and tell you nothing. Audit privileged and administrative activity broadly, audit application accounts narrowly, and audit access to sensitive columns found by discovery. You can sanity-check volume on the database before turning collection on:

-- Which unified audit policies are enabled, and for whom
SELECT policy_name, enabled_option, entity_name
FROM   audit_unified_enabled_policies;

-- Records per day per user over the last week: the number Data Safe will collect
SELECT TRUNC(event_timestamp) AS day, dbusername, COUNT(*) AS records
FROM   unified_audit_trail
WHERE  event_timestamp > SYSTIMESTAMP - INTERVAL '7' DAY
GROUP  BY TRUNC(event_timestamp), dbusername
ORDER  BY records DESC;

Alerts and SQL Firewall

Alerts evaluate collected audit records against alert policies, such as failed logins, changes to audit policies, user or profile changes, and raise near-real-time alerts you can review in Data Safe and route onward through OCI's eventing and notification services. An alert is only as fast and complete as audit collection, so the auditing decisions above also decide what can alert.

SQL Firewall is built into Oracle Database 23ai and later, and Data Safe manages it centrally. The workflow is allow-listing. You start a collection for an application account while it runs normal workload, so the firewall records the SQL statements it issues and the connection context, such as client IP addresses and programs. You then generate a policy from that collection, review it and deploy it. Enforcement has two modes: observe and log violations, where unexpected statements still run but are recorded, and block and log violations, where they are refused. Run in observe mode through at least a full business cycle, including month-end jobs, before switching to block, or you will block a legitimate report the first time it runs. SQL Firewall complements, not replaces, parameterised queries in the application.

Worked example: a payments database

Consider a payments service on an Oracle Base Database system in a private subnet, plus a nightly clone for the test team. Week one: create a Data Safe private endpoint in the database's VCN, open the listener port from it, create the service account, grant assessment, audit collection, audit setting and discovery roles, and register. Run security and user assessments; the user assessment shows the application account holding a powerful role granted during an old incident. Remove it, rerun, and set the clean run as baseline with a weekly schedule.

Week two: run discovery, and have the payments data owner review the model, adding a relationship between CARDS.CUSTOMER_ID and DISPUTES.CUST_REF that has no declared constraint. Create a masking policy from the model and add it to the clone pipeline against the test target only. Week three: provision administrative-activity and user-activity audit policies, plus a custom policy on the sensitive tables limited to non-application users. The volume query shows about 400,000 records a month, inside the free allowance. Set online retention to 12 months and archive to 72 to meet a seven-year requirement. Add alerts for failed administrator logins and audit-policy changes. If the database moves to 23ai, start a SQL Firewall collection for the application account and run it in observe mode for a month.

Data Safe does not hold the encryption keys or database backups in this design; OCI Vault and the database service do. For the database side of this setup, see OCI Base Database Service.

Failure modes

• Registration fails on the network. The private endpoint's subnet cannot reach the listener, or TCPS is configured on one side only. Test the path from the endpoint's subnet first.
• A feature is greyed out. The corresponding role was not granted to the service account. Grant it and refresh the target.
• Audit collection stops mid-month. The target hit the free record limit without paid usage enabled. Decide in advance which targets may incur charges.
• Audit volume explodes. A broad policy audits application reads. Narrow it to privileged users and sensitive objects.
• Masked copy breaks joins. An undeclared relationship was missing from the sensitive data model.
• Masking pointed at production. Prevent it with compartment-scoped IAM, not with care.
• SQL Firewall blocks a legitimate job. The collection window missed periodic workload. Collect longer and observe before blocking.

What to do next

1. Inventory your Oracle databases by location: Autonomous, VCN-hosted, on-premises or other cloud, and choose the connectivity method for each.
2. Create the IAM groups and policies above, separating audit readers and masking operators from Data Safe administrators.
3. Register one database end to end and run security and user assessments to prove the path and roles.
4. Fix the top findings, set baselines and schedule recurring assessments with drift reporting.
5. Run discovery, have data owners review the sensitive data model, and add masking to every production-to-test clone pipeline.
6. Measure audit volume with the query above before enabling collection, then set retention and paid-usage decisions per target.
7. On 23ai databases, start SQL Firewall collection for application accounts in observe mode.