Data Safe - Introduction

Oracle Data Safe learner guide

Oracle Data SafeAssess risk, discover sensitive data, audit activity, and mask safely

It focuses on what Data Safe helps you do operationally: review security posture, find risky identities, centralize auditing, locate sensitive data, and produce safer non-production copies.

Contents

01 Why Data Safe matters02 Where it fits03 Capability map04 Assessments05 Activity Auditing06 Discovery and Masking07 Operating model08 First 30 days09 Knowledge check

Section 01

Why Data Safe matters

Database security work is often fragmented. One process checks configuration drift, another stores audit logs, another team scans for PII, and another team writes masking logic for test refreshes. Data Safe is useful because it turns those separate jobs into one security workflow.

Key idea

The best way to think about Data Safe is as a control plane for database security posture: assess the target, identify risky accounts, discover sensitive data, monitor activity, and mask data before it leaves production.

For DBAs

Prioritize hardening tasks, review powerful accounts, and prove controls are in place.

For security teams

Centralize audit evidence and review alerts in a more consistent way.

For compliance

Map controls to real database evidence instead of relying on manual screenshots.

For developers and QA

Receive masked copies of production data without exposing real customer secrets.

Section 02

What Oracle Data Safe is and where it fits

Oracle Data Safe is a managed service for securing Oracle databases. In practice, teams register targets, collect metadata and audit information, run security and user assessments, discover sensitive columns, and create masking models for safe downstream use. It fits above the database features you already rely on, such as privileges, Unified Auditing, and encryption.

Mental model

Data Safe does not replace database security features. It helps you evaluate, organize, and operationalize them.

Need	How Data Safe helps	Outcome
Configuration hardening	Security Assessment and baselines	Ranked remediation instead of scattered manual checks
Privilege review	User Assessment and account analysis	Faster identification of over-privileged or stale accounts
Audit evidence	Activity Auditing, reports, and alerts	Searchable activity trails and stronger investigation context
PII inventory	Sensitive Data Discovery models	Better visibility into where regulated data actually lives
Safe non-prod refreshes	Data Masking formats and policies	Realistic but de-identified data for dev and test

Section 03

Capability map

Security Assessment

Scores security posture and helps spot configuration drift over time.

User Assessment

Highlights risky users, roles, privileges, and password posture.

Activity Auditing

Centralizes audit activity so suspicious events are easier to analyze.

Sensitive Data Discovery

Scans schemas for likely sensitive columns and groups them into usable models.

Data Masking

Transforms sensitive data for lower environments while preserving usefulness.

Alerts and adjacent controls

Teams often combine audit alerts with newer controls such as SQL Firewall where supported.

Important distinction

Discovery tells you where sensitive data is. Masking changes values so the data can be used more safely outside production. Discovery usually comes first.

Section 04

Assessments: configuration risk and powerful users

Security Assessment and User Assessment answer different questions. Security Assessment asks whether the database is configured safely. User Assessment asks which accounts or privileges create unnecessary risk. Strong teams run both and combine the findings into one remediation list.

Security Assessment mindset

• Use it to detect drift after upgrades, emergency changes, or team turnover.
• Compare snapshots over time instead of reading one report in isolation.
• Separate high-impact issues from noisy low-priority findings.

User Assessment mindset

• Look for stale accounts, broad roles, and accounts that should not be interactive.
• Review both granted roles and direct system privileges.
• Pay special attention to shared accounts and accounts that can delegate privileges.

SQL - Risky roles overview

-- Start with role-based exposure, not just one account at a time
SELECT r.grantee,
       LISTAGG(r.granted_role, ', ') WITHIN GROUP (ORDER BY r.granted_role) AS roles,
       MAX(CASE WHEN r.admin_option = 'YES' THEN 'YES' ELSE 'NO' END) AS can_delegate
FROM   dba_role_privs r
WHERE  r.granted_role IN ('DBA', 'RESOURCE', 'EXP_FULL_DATABASE', 'IMP_FULL_DATABASE')
GROUP BY r.grantee
ORDER BY r.grantee;

SQL - Direct system privileges

-- Direct grants are easy to miss during reviews
SELECT p.grantee,
       p.privilege,
       p.admin_option
FROM   dba_sys_privs p
WHERE  p.privilege IN (
         'ALTER SYSTEM',
         'CREATE USER',
         'DROP USER',
         'GRANT ANY PRIVILEGE',
         'GRANT ANY ROLE')
ORDER BY p.grantee, p.privilege;

Reading tip

For every risky account finding, ask two questions: Is the account still needed? If yes, is the breadth of privilege still justified?

Section 05

Activity Auditing: evidence, alerts, and useful scope

Auditing is most useful when it is targeted. If you audit everything, you create noise. If you audit only logons, you miss privilege abuse and schema-change evidence. A strong starting point is administrator actions, identity changes, privilege changes, and access to a shortlist of sensitive objects.

Audit focus	Why it matters	Typical signals
Account lifecycle	Privileged account creation or changes often indicate elevated risk	CREATE USER, ALTER USER, DROP USER
Privilege management	Tracks who can widen someone else's access	GRANT, REVOKE, role changes
Schema changes	Useful for change control and investigations	CREATE TABLE, ALTER TABLE, DROP object
Sensitive data access	Shows which identities touched regulated data	SELECT or DML against key application tables

SQL - Unified audit policy example

-- Focus on high-value administrative actions first
CREATE AUDIT POLICY admin_change_pol
  ACTIONS
    CREATE USER,
    ALTER USER,
    DROP USER,
    GRANT,
    REVOKE;

AUDIT POLICY admin_change_pol;

SQL - Read recent audit events

-- Validate that your policy is producing useful evidence
SELECT event_timestamp,
       dbusername,
       action_name,
       object_schema,
       object_name,
       return_code
FROM   unified_audit_trail
WHERE  action_name IN ('CREATE USER', 'ALTER USER', 'GRANT', 'REVOKE')
ORDER BY event_timestamp DESC
FETCH FIRST 20 ROWS ONLY;

Noise control

Do not start by auditing every action in every schema. Begin with a high-signal set of events and expand only after the results are useful.

Section 06

Sensitive Data Discovery and Data Masking

Discovery and masking are where many teams feel immediate value. Discovery shows where email, payment, health, national-identifier, or compensation data may exist. Masking then turns that map into safe copies for development, QA, analytics, and training environments.

Discovery: think in models, not one-off scans

A useful discovery run does more than list columns. It creates a durable model of sensitive data in the target, so you can review, refine, and reuse classifications.

SQL - Candidate sensitive columns

-- A simple learner-friendly query for columns worth reviewing
SELECT owner,
       table_name,
       column_name,
       data_type
FROM   dba_tab_columns
WHERE  REGEXP_LIKE(column_name,
         'SSN|SOCIAL|NATIONAL|TAX|EMAIL|PHONE|CARD|CREDIT|DOB|BIRTH|SALARY|PAY',
         'i')
ORDER BY owner, table_name, column_id;

Good masking is not just hiding values. It should preserve test usefulness by keeping format, joins, and application expectations intact.

Best fit for masking

Non-production refreshes, training databases, vendor troubleshooting copies, analytics sandboxes.

Common mistakes

Masking only one table, breaking join keys, or generating values that fail application validation.

Useful formats

Deterministic substitution, shuffling, partial masking, random date shifts, and conditional rules.

Validation after masking

Check row counts, referential integrity, uniqueness assumptions, and application-level patterns.

SQL - Post-mask validation checks

-- Example 1: validate email-like shape after masking
SELECT COUNT(*) AS bad_email_rows
FROM   customers_masked
WHERE  email NOT LIKE '%@%';

-- Example 2: validate parent-child integrity still holds
SELECT COUNT(*) AS broken_order_links
FROM   orders_masked o
       LEFT JOIN customers_masked c
         ON c.customer_id = o.customer_id
WHERE  c.customer_id IS NULL;

Section 07

Operating model: how teams actually use it

Mature teams do not run Data Safe once and forget it. They schedule assessments, review deltas, tune audit scope, refresh sensitive-data models, and keep masking policies aligned with application change.

Weekly

Review new high-risk findings, audit alerts, and accounts with newly expanded privileges.

Monthly

Re-run assessments, compare baselines, and verify that remediation reduced exposure.

Before each refresh

Validate masking coverage for newly added tables, columns, or integrations.

After major releases

Review discovery models and audit policies because new releases often add new sensitive fields.

Good habit

Tie every important report to an owner and a next action. Reports without ownership become shelfware.

Section 08

A practical first-30-days rollout plan

Week 1: onboard and inventory

Register the most important targets, confirm connectivity, and document business owners.

Week 2: run both assessments

Triage high-severity findings and identify the best privileged-account cleanup opportunities.

Week 3: enable focused auditing

Start with administrator actions and a shortlist of high-value objects.

Week 4: discover and mask

Create a sensitive-data model, build a first masking policy, and validate application behavior.

Avoid the common trap

Do not wait for a perfect enterprise-wide design before starting. A narrow, well-run rollout on a few critical databases teaches more than a giant plan that never reaches production.

Section 09

Knowledge check

These questions test understanding, not memorization. Read the explanations after you submit - that is where the real learning happens.

Q1. Which statement best captures the relationship between Sensitive Data Discovery and Data Masking?

They are the same feature with two different names.

Discovery finds and classifies sensitive data; masking changes data values for safe downstream use.

Discovery runs only after masking is complete.

Masking is only for production, discovery is only for test databases.

Correct answer: Discovery finds and classifies, masking transforms. Discovery gives visibility into where sensitive data lives. Masking uses that understanding to produce safer non-production copies without exposing real values.

Q2. Why is User Assessment not the same as Security Assessment?

User Assessment measures storage growth, while Security Assessment measures CPU use.

User Assessment is for developers only, while Security Assessment is for DBAs only.

User Assessment focuses on account and privilege risk; Security Assessment focuses on database security posture and configuration.

Security Assessment replaces auditing, while User Assessment replaces masking.

Correct answer: User Assessment looks at identity risk, Security Assessment looks at configuration risk. Strong operations use both because accounts and configuration can each create serious exposure.

Q3. What is the best starting point for activity auditing in a new rollout?

Audit a focused set of high-value actions such as account changes, grants, revokes, and sensitive object access.

Audit every statement in every schema immediately.

Audit only failed logons and nothing else.

Skip auditing until all masking work is complete.

Correct answer: Start focused. Good auditing begins with high-signal events. If you start too broad, teams drown in noise and stop trusting the results.

Q4. Which masking outcome is the most useful in practice?

All values are replaced with NULL so nothing can leak.

Every text field is replaced with exactly the same dummy word.

Only one table is masked, because joins are not important in test environments.

Values are de-identified while still preserving application usefulness and key relationships.

Correct answer: Useful masked data still behaves like data. If the application breaks, referential integrity fails, or validation rules collapse, the masked copy is much less valuable.

Q5. A team runs a discovery scan and finds columns likely to contain email, salary, and national ID data. What is the strongest next step?

Ignore the findings until the next annual audit.

Review and refine the sensitive-data model, then use it to drive masking and monitoring priorities.

Drop the columns immediately from production.

Disable auditing because discovery already covers compliance needs.

Correct answer: Turn findings into action. Discovery is most valuable when it feeds masking design, audit scope, and ownership decisions for sensitive data.

Q6. What is the biggest operational mistake after onboarding Data Safe?

Running reports too often.

Using code blocks with copy buttons.

Treating reports as passive output instead of assigning owners and remediation actions.

Reviewing privileges before looking at storage space.

Correct answer: Unowned findings rarely reduce risk. Security posture improves when each high-value finding has an owner, a decision, and a due date.