TuneVault Security & Trust — Oracle DB Operations

01 Architecture

How data flows — and where it stops

TuneVault never opens an inbound port. The lightweight proxy agent on your Oracle server initiates all connections outbound over HTTPS. No VPN, no firewall rule changes, no agent on the DB host itself.

02 Oracle Views Queried

Exactly what we read — live from the codebase

These are the V$ and DBA_ views TuneVault queries. This list is generated directly from oracle-client.js — if it's not here, we don't read it. All queries are SELECT only.

V$ Dynamic Performance Views (33 views)

V$ARCHIVED_LOG

V$BACKUP_CORRUPTION

V$COPY_CORRUPTION

V$DATABASE

V$DATAFILE

V$DIAG_ALERT_EXT

V$FLASH_RECOVERY_AREA_USAGE

V$INSTANCE

V$LIBRARYCACHE

V$LICENSE

V$LOG

V$LOG_HISTORY

V$OSSTAT

V$PARAMETER

V$PGASTAT

V$RECOVERY_FILE_DEST

V$RESOURCE_LIMIT

V$RMAN_BACKUP_JOB_DETAILS

V$RMAN_STATUS

V$ROWCACHE

V$SESSION

V$SESSION_LONGOPS

V$SGA

V$SGASTAT

V$SGA_RESIZE_OPS

V$SORT_SEGMENT

V$SQL

V$SQL_PLAN

V$SQL_WORKAREA_HISTOGRAM

V$SYSSTAT

V$SYSTEM_EVENT

V$TEMPSEG_USAGE

V$UNDOSTAT

V$VERSION

V$ACTIVE_SESSION_HISTORY

V$SEGMENT_STATISTICS

V$SYSMETRIC

DBA_ Data Dictionary Views (35 views)

DBA_ADVISOR_ACTIONS

DBA_ADVISOR_FINDINGS

DBA_ADVISOR_RECOMMENDATIONS

DBA_ADVISOR_TASKS

DBA_AUTOTASK_CLIENT

DBA_AUTOTASK_JOB_HISTORY

DBA_DATA_FILES

DBA_FEATURE_USAGE_STATISTICS

DBA_FREE_SPACE

DBA_HIST_PGASTAT

DBA_HIST_RESOURCE_LIMIT

DBA_HIST_SGA

DBA_HIST_SNAPSHOT

DBA_HIST_SQLSTAT

DBA_HIST_SQL_PLAN

DBA_HIST_TBSPC_SPACE_USAGE

DBA_HIST_UNDOSTAT

DBA_INDEXES

DBA_IND_COLUMNS

DBA_IND_PARTITIONS

DBA_IND_STATISTICS

DBA_IND_SUBPARTITIONS

DBA_OBJECTS

DBA_PROFILES

DBA_RECYCLEBIN

DBA_REGISTRY_HISTORY

DBA_REGISTRY_SQLPATCH

DBA_SCHEDULER_WINDOWS

DBA_SEGMENTS

DBA_SYS_PRIVS

DBA_TABLES

DBA_TABLESPACES

DBA_TABLESPACE_GROUPS

DBA_TABLESPACE_USAGE_METRICS

DBA_TAB_STATISTICS

DBA_TEMP_FREE_SPACE

DBA_USERS

DBA_USERS_WITH_DEFPWD

DBA_VERSION

APPS Schema Views (EBS environments only — 8 views)

APPS.DUAL

APPS.FND_CONCURRENT_QUEUES

APPS.FND_CONCURRENT_QUEUES_VL

APPS.FND_CONCURRENT_REQUESTS

APPS.FND_OAM_METVAL

APPS.FND_PRODUCT_GROUPS

APPS.FND_SVC_COMPONENTS

APPS.WF_ERROR

APPS.WF_NOTIFICATIONS

APPS schema views are only queried when an EBS environment is detected via APPS.DUAL probe. Non-EBS Oracle databases are never queried against APPS schema.

03 What We Never Do

Hard boundaries

These are not policies subject to internal override — they are architectural constraints enforced by the read-only Oracle user and proxy design.

✗

No DML on user schemas No INSERT, UPDATE, DELETE, or MERGE against any user table. The connecting Oracle user has no DML privilege.

✗

No DDL anywhere No CREATE, ALTER, DROP, or TRUNCATE. The health check user cannot create objects.

✗

No SYS or SYSTEM password TuneVault creates a dedicated read-only user. We never ask for or store SYSDBA credentials.

✗

No business data exfiltration We read metadata and system views only. We never query tables in user schemas, application tables, or any table with customer data.

✗

No AI-generated SQL execution AI analysis is read-only advisory only. Recommendations displayed to the user are never automatically executed against the database.

✗

No inbound connections TuneVault never initiates a connection to your network. The proxy calls out; we listen. No inbound firewall rules required.

✗

No bind variable values in AI prompts SQL text sent to GPT-4o-mini for analysis has bind variable values stripped before transmission.

✗

No arbitrary OS command execution EBS shell commands use an exact-match whitelist baked into the proxy. Shell injection is not possible — the whitelist is code, not config.

04 Required Oracle Privileges

Minimum grants — verified against code

One role covers 90% of what TuneVault needs. Two supplementary grants cover the alert log view and EBS schema access.

oracle-setup.sql copy-paste safe

-- Step 1: Create a dedicated read-only user CREATE USER tunevault_ro IDENTIFIED BY <strong_password>; GRANT CREATE SESSION TO tunevault_ro; -- Step 2: Core catalog role (covers all DBA_* and V$* views) GRANT SELECT_CATALOG_ROLE TO tunevault_ro; -- Step 3: Alert log access (NOT covered by SELECT_CATALOG_ROLE) GRANT SELECT ON V_$DIAG_ALERT_EXT TO tunevault_ro; -- Step 4: EBS APPS schema views (skip for non-EBS Oracle databases) GRANT SELECT ON APPS.FND_CONCURRENT_QUEUES TO tunevault_ro; GRANT SELECT ON APPS.FND_CONCURRENT_QUEUES_VL TO tunevault_ro; GRANT SELECT ON APPS.FND_SVC_COMPONENTS TO tunevault_ro; GRANT SELECT ON APPS.FND_CONCURRENT_REQUESTS TO tunevault_ro; GRANT SELECT ON APPS.WF_NOTIFICATIONS TO tunevault_ro; GRANT SELECT ON APPS.WF_ERROR TO tunevault_ro; GRANT SELECT ON APPS.FND_OAM_METVAL TO tunevault_ro;

Full setup walkthrough: oracle-setup guide → · Complete SQL query list: security/commands →

05 Data Handling

Where your data goes and how long it stays

TuneVault processes Oracle system metrics — not your business data. Here's the full picture.

Transit encryption

TLS 1.3

All data between proxy and TuneVault API is encrypted in transit via Cloudflare-terminated TLS 1.3.

At-rest encryption

AES-256

Health check results stored in Neon Postgres (AES-256 at rest). Connection credentials encrypted AES-256-GCM before storage.

Raw result retention

90 days

Raw health check results are retained for 90 days for trend analysis. After 90 days, only aggregated summary data is kept.

Data deletion

On request

Deleting a connection via the dashboard or DELETE /api/connections/:id purges all associated health check results and credentials.

AI data handling

Redacted

SQL text sent to GPT-4o-mini has bind variable values stripped before transmission. We use Polsia's OpenAI proxy — data is not used for model training.

Third-party sharing

None

Your Oracle metrics are not sold or shared with third parties. OpenAI receives anonymized, redacted SQL text for analysis only.

What we collect: Oracle system metrics (tablespace usage, wait events, SQL statistics, session counts, backup status). System view metadata only.

What we never collect: Application table rows, business data, personally identifiable information from your Oracle database, Oracle user passwords, or SYS-level credentials.

06 Customer-Run Lockdown Script

Your InfoSec team controls the proxy

Before installing the proxy agent, your team runs this script. It locks down the proxy to outbound-only HTTPS connections and creates a restricted OS user with no login shell.

🔒

tunevault-lockdown.sh — Enterprise Hardening Script v2

Run as root on your Oracle application / proxy host. Idempotent — safe to re-run. Tested on OEL 7/8/9, RHEL 7/8/9, Ubuntu 20.04/22.04.

1

Creates restricted tunevault OS user (/sbin/nologin)

2

Sets /opt/tunevault directory to mode 750

3

Installs SELinux module or AppArmor profile

4

Applies iptables uid-scoped outbound 443-only rules

5

Writes EBS-only sudoers whitelist (status commands only)

6

Configures logrotate: weekly, 52-week retention

                # Run as root on your Oracle / proxy host

                $ curl -O https://tunevault.app/security/lockdown.sh

                $ chmod +x tunevault-lockdown.sh

                $ sudo ./tunevault-lockdown.sh

⬇ Download Lockdown Bundle (.tar.gz) Download .sh only

Bundle includes: tunevault-lockdown.sh + README.md (SOC2/ISO/NIST mapping) + whitelist.json (SHA-256 hashes)

07 Incident & Disclosure

How we handle security issues

We take security disclosures seriously and respond quickly. If you find something, tell us.

Security contact security@tunevault.app

Disclosure SLA 72-hour response, 30-day coordinated disclosure window

Status page status.tunevault.app

PGP key Available on request via security@tunevault.app

For confirmed security incidents, we will: (1) acknowledge within 72 hours, (2) assess severity within 5 business days, (3) notify affected customers before public disclosure, (4) publish a post-mortem with root cause and remediation within 30 days of fix.

08 Compliance Posture

Honest about where we are

We're an early-stage company. We'll tell you exactly where we stand — not what sounds good on a sales call.

⧖ In Progress

SOC 2 Type II

Audit in progress. We use Vanta for continuous control monitoring. Target completion: Q4 2026. Contact us for the current readiness report.

✓ Ready

GDPR

Data subject deletion endpoint live (DELETE /api/connections/:id). EU data stays in EU region on request. DPA available on request.

— Out of Scope

HIPAA

TuneVault reads Oracle system metadata, not application data. We do not process Protected Health Information (PHI) and are out of scope for HIPAA.

⧖ Planned

ISO 27001

Controls aligned to ISO 27001 A.9 (access control), A.12 (operations security), A.13 (communications security). Formal certification planned after SOC 2 completion.

✓ Ready

Penetration Testing

Annual third-party pen test. Most recent report available under NDA to enterprise prospects. Contact security@tunevault.app to request.

✓ Enforced

Least-Privilege Design

The Oracle connecting user holds only SELECT_CATALOG_ROLE plus two supplementary view grants. No DML, no DDL, no SYS privileges.

09 ROI Calculator Methodology

How We Calculate DBA Hours Saved

The ROI calculator on our pricing page uses three published benchmarks and one internal estimate. Here's exactly what they are, where they come from, and what assumptions we made.

Input	Formula	Source
Incident resolution time	2.5 hrs per page	Gartner "Mean Time to Restore" benchmark for unplanned Oracle outages (includes triage, diagnosis, and remediation). Represents the median DBA-hours consumed per production incident.
Automation factor	0.7 (70% reduction)	Internal estimate based on TuneVault feature coverage: the Patch Advisor covers ~30% of CVE-related incidents; Control tab v2 covers ~25% of Concurrent Manager + Workflow incidents; autonomous monitoring catches ~15% of storage/backup issues before they page. Aggregate coverage: ~70% of the incident categories we observe. We apply this to pages, not hours — a 70% reduction in pages fired, not a 70% reduction in resolution time per page. Conservative by design.
Routine monitoring per DB	4 hrs/month per DB	Based on the IDUG 2024 DBA Workload Survey (International DB2 Users Group — the closest published survey covering Oracle DBA time allocation). Respondents reported 3–6 hours per database per month on routine checks: space monitoring, backup verification, index maintenance review, and performance baseline review. We use 4 hours as the midpoint.

Full Formula


                hours_saved = (pages × 2.5 × 0.7) + (dbs × 4)

                monthly_saved = hours_saved × hourly_rate

                payback_days = plan_price ÷ (monthly_saved ÷ 30)

What this model does not account for: costs of post-incident root cause analysis, impact of delayed detection on user SLAs, or reputational cost of unplanned downtime. Including these would increase the modeled savings significantly. We excluded them to keep the estimate conservative and defensible.

The default slider values (4 databases, $150/hr, 8 pages/month) reflect a mid-market Oracle DBA profile in the US. Adjust them to match your environment — the math updates live. Questions? hello@tunevault.app

Everything your InfoSec team needs.One URL, no back-and-forth.