01 — Architecture

How the Connection Works

The proxy runs on your server. It calls out to TuneVault. TuneVault never calls in. No inbound firewall rules, no VPN, no SSH from our side.

🚫

No inbound ports opened

TuneVault never initiates connections to your servers. Your firewall has zero new inbound rules to manage.

🚫

No SSH from TuneVault

We don't hold SSH keys, don't open SSH sessions, and have no remote shell access to your infrastructure.

🔑

Hashed API key only

The proxy authenticates with a 64-hex API key generated locally at install time. We store only the SHA-256 hash — the plaintext never leaves your server.

🛡

TLS encrypted in transit

All proxy traffic uses TLS 1.2+ over HTTPS. The proxy makes outbound connections only — no inbound firewall changes are required on your side.

🏃

Proxy runs as isolated user

The lockdown script (§4 below) creates a tunevault system user with /sbin/nologin, restricted to /opt/tunevault only.

📋

No plaintext Oracle credentials stored

Oracle credentials are encrypted at rest with AES-256-GCM — only ciphertext is stored in our database. Direct-mode connections can also be used session-only with no persistence at all. Plaintext never touches disk or our servers.

01b — Credential Storage Model

How Credentials Are Handled by Connection Mode

Storage behavior depends on how you connect. No mode ever stores plaintext passwords.

Connection Mode	Oracle Credentials Stored?	Storage Method	Plaintext on Disk?
Direct TCP — session-only	No — not persisted	In-process only, discarded after use	Never
Direct TCP — saved connection	Yes — encrypted at rest	AES-256-GCM ciphertext in `oracle_connections`	Never
Proxy / HTTP agent	API key only	API key stored as AES-256 ciphertext; Oracle OS auth via proxy — no password transmitted	Never
Agent tunnel (install.sh)	No Oracle password stored	OS authentication via tunnel; tunnel token encrypted at rest	Never

02 — Command Whitelist

Every Permitted EBS Control Command

These are the only EBS operational commands TuneVault can issue. The list is seeded in the database at deployment time and validated server-side on every request — user input never flows into command construction.

+ Full SQL query whitelist (200+ checks) →

Slug	Label	Category	Command Preview	Risk	Dry-run
Loading live whitelist from database...

Hard enforcement: Anything not in this table returns HTTP 403 and an audit_log rejection row — before any Oracle command is even considered. The slug validation happens against the database, not a client-supplied list. If a slug isn't in ebs_control_commands, it cannot be executed, ever.

03 — Audit Trail

Every Action Logged. Immutably.

The audit_log table captures every EBS control preview attempt — allowed and rejected — as append-only rows. No row is ever updated or deleted.

audit_log — append-only, no UPDATE/DELETE

CREATE TABLE audit_log (
  id               BIGSERIAL    PRIMARY KEY,
  user_id          INTEGER      NOT NULL REFERENCES users(id),
  action           TEXT         NOT NULL,   -- e.g. 'ebs_control.preview'
  slug             TEXT         NOT NULL,   -- command slug attempted
  allowed          BOOLEAN      NOT NULL,   -- true = whitelisted, false = rejected
  rejection_reason TEXT,                     -- null when allowed=true
  metadata         JSONB        DEFAULT '{}', -- ip, user_agent, risk_level
  created_at       TIMESTAMPTZ  NOT NULL DEFAULT NOW()
);

-- No UPDATE/DELETE permissions granted on this table.
-- Application role has INSERT + SELECT only.

Sample row — allowed attempt

id 4291

user_id 837

action 'ebs_control.preview'

slug 'cm_bounce'

allowed true

rejection_reason null

metadata {"ip": "203.0.113.45", "user_agent": "Mozilla/5.0…", "risk_level": "medium"}

created_at "2026-05-11T10:14:22Z"

📌

Every rejection logged

Non-whitelisted slug attempts write a row with allowed=false and a rejection_reason — before returning HTTP 403.

🔒

Append-only by design

The application DB role has INSERT + SELECT only on audit_log. No UPDATE or DELETE is possible from the API tier.

🌐

IP captured on every row

The originating IP and user-agent are stored in metadata. Cross-reference with your WAF logs for full attribution.

♾

No retention limit

Audit rows are retained indefinitely. No automated purge job. Contact support@tunevault.app to request a log export.

04 — Data Handling

What We Read, What We Never Touch

TuneVault reads performance and configuration metadata from Oracle system views. We never read table data, application schemas, or anything that could contain customer PII.

✅

What we read

READ

📊 V$SQL, V$SESSION, V$SYSSTAT — performance metrics

💾 DBA_TABLESPACE_USAGE_METRICS — storage utilisation

⚡ V$SYSTEM_EVENT — wait event statistics

🔒 DBA_USERS, DBA_SYS_PRIVS — security posture

📋 APPS.FND_CONCURRENT_QUEUES — EBS CM status

⚙ APPS.FND_SVC_COMPONENTS — EBS service health

📂 V$RMAN_BACKUP_JOB_DETAILS — backup freshness

🧩 DBA_OBJECTS WHERE STATUS='INVALID' — invalid objects

🚫

What we never read

NEVER

🚫 Application table data (no SELECT on business tables)

🚫 Customer PII — names, emails, addresses, phone numbers

🚫 Financial records — invoices, payments, orders

🚫 HR data — employee records, salaries, org structures

🚫 Oracle credentials — username/password are transient only

🚫 Schema DDL of application tables

🚫 BLOB/CLOB contents — documents, attachments, images

🚫 Any table outside V$, GV$, DBA_*, APPS.FND_* views

Retention Windows

Health check results

90 days

Raw metrics from each Oracle health check run. Auto-deleted after 90 days unless you request archival.

AI analysis text

90 days

Generated recommendations retained alongside the health check that produced them.

Audit log rows

Indefinite

EBS control audit rows are never purged. Available for export on request: support@tunevault.app

Connection credentials

AES-256 encrypted

Oracle passwords are encrypted at rest with AES-256-GCM — plaintext is never written to disk. Direct-mode connections can also be session-only with no persistence. Proxy API keys are stored as SHA-256 hash only.

05 — Lockdown Bundle

Customer-Run Hardening Scripts

Your security team runs these scripts on your servers — not us. The bundle contains a hardening script, README with compliance framework mappings, and a command hash whitelist for integrity verification.

📦

tunevault-lockdown-bundle.tar.gz

A self-contained archive your team can audit before running anything. The hardening script is idempotent — safe to re-run at any time. Nothing in the bundle requires an internet connection to execute.

📄 tunevault-lockdown.sh — hardening script (root-only, idempotent)

📄 README.md — plain-English explanation + SOC2/ISO 27001/NIST framework mapping

📄 whitelist.json — machine-readable command catalog with SHA-256 hashes

⬇ Download lockdown bundle (.tar.gz) ⬇ tunevault-lockdown.sh only

What the lockdown script does

STEP 1

Dedicated OS user

Creates tunevault system user with /sbin/nologin — no interactive shell, no home directory, system account only.

STEP 2

Directory lockdown

Installs proxy under /opt/tunevault with mode 750. Log directory is 700. No other users can read proxy files.

STEP 3

SELinux / AppArmor profile

Restricts filesystem access to /opt/tunevault and /tmp only. Oracle binary and scripts remain protected.

STEP 4

Outbound firewall rules

iptables/firewalld rules allowing ONLY outbound 443 to *.tunevault.app for the proxy user. All other outbound traffic is blocked.

STEP 5

Sudoers whitelist

Grants tunevault user permission to run ONLY the listed admanagedsrvctl.sh status commands as oracle. No start/stop/restart.

STEP 6

Audit logging

Installs logrotate config to manage /var/log/tunevault-audit.log — every action logged with timestamp and syslog tag.

This script is your source of truth. TuneVault cannot modify what's locked down here. Run it before installing the proxy. The lockdown persists independently of any TuneVault software update.

06 — Threat Model

What an Attacker Would Have to Compromise

The table below maps each realistic attack scenario to the controls that block it. Every row is a question your security team will ask. Every cell is a concrete, verifiable answer.

Attack Scenario	What the Attacker Needs	Controls That Block It	Risk
Access another tenant's Oracle connection	Valid session + target connection ID	Server-side ownership check on every connection operation. Guessing an integer ID returns 404, not the connection. All credential columns are AES-256 encrypted — even a DB dump is ciphertext only.	BLOCKED
Steal Oracle credentials from TuneVault's database	Full Neon DB dump + the `ENCRYPTION_KEY` env var (separate secret)	AES-256-GCM encryption at rest. The key is a Render environment variable — never in DB, never in git, never in logs. Compromising only the DB yields ciphertext with no decryption path.	BLOCKED
Inject arbitrary commands via the agent channel	A valid per-tunnel API key + ability to intercept TLS	Agent enforces a hard command allowlist — only named commands with typed argument validation execute. No shell=True, no string interpolation. TLS validates server certificate via system CA bundle.	BLOCKED
Escalate from viewer → admin via API manipulation	Valid session with any role	RBAC enforced server-side via `requireRole()` middleware. Client-side visibility is cosmetic only — never trusted for access decisions. Role hierarchy: viewer → junior_dba → senior_dba → admin.	BLOCKED
Reuse a magic link / steal a session	Intercept email or session cookie	Magic links are single-use (database-enforced), 15-minute TTL, 256-bit entropy. Session cookies are HttpOnly + Secure + SameSite=Lax. Auth endpoint rate-limited: 10 requests/minute per IP.	HARDENED
Compromise the TuneVault cloud service	Full Render platform access	Even with cloud access, attacker can only issue commands from the agent channel allowlist. No shell access to the customer host is possible — agent is outbound-only, no inbound port, no SSH. Credentials still encrypted.	HARDENED
Run arbitrary SQL via SQL Console	senior_dba session + target connection ownership	SQL Console requires `senior_dba` role. Execution enforces connection ownership server-side. Every query logged to `sql_audit_log` with user, SQL text, connection, duration, and outcome — permanent append-only.	AUDITED

🧅

Defense in depth

Network layer (TLS, outbound-only) → authentication (session + API key) → authorization (RBAC + ownership) → data layer (encryption at rest). No single bypass yields credentials.

📋

Audit trail everywhere

SQL Console, SSH commands, EBS control actions, agent exec — all write to separate, append-only audit tables. No action can erase its own log row.

🔐

Encrypted-at-rest guarantee

AES-256-GCM with a random IV per encryption. Authentication tag prevents ciphertext tampering. Key stored separately from data — never in the same compromise boundary.

07 — Compliance & Data Residency

Residency, Retention & Your Rights

Answers to the procurement checklist questions that follow every Oracle tool evaluation in an enterprise environment.

🌐

Data Residency

TuneVault infrastructure runs in the United States (Render / Neon — US region). Oracle performance metrics collected during a health check are processed and stored in the US. No data is replicated to EU, APAC, or other regions unless you explicitly export it.

🗑️

Deletion on Request

Email support@tunevault.app to request deletion of your account, connections, and health check history. We complete deletion within 5 business days and confirm in writing. Append-only audit rows (SQL Console log, EBS control log) are retained per our data retention policy unless you have a specific regulatory reason for purge.

🤝

No Third-Party Data Sharing

Your Oracle performance metrics, connection details, and health check results are never shared with or sold to third parties. AI analysis uses OpenAI models via our managed API proxy — your data is subject to OpenAI's enterprise API data handling policy (not used for training). No analytics platform, ad network, or data broker receives your data.

📅

Retention Policy

Health check metrics and AI analysis: 90 days, then auto-purged. Audit log rows (SQL Console, EBS control): indefinite — these are your compliance records. Oracle credentials: deleted immediately on connection removal. API keys: deleted on rotation or account deletion.

📤

Data Export

Health check results and audit logs are exportable in PDF and XLSX formats via the built-in report generator. Contact support@tunevault.app for a full account data export in JSON format.

📬

Security Disclosure

Report vulnerabilities to support@tunevault.app. We aim to respond within 24 hours for critical issues and 72 hours for medium severity. Please don't publish vulnerability details until a fix has been deployed. We don't have a bug bounty programme at this time but acknowledge every valid report.

Minimum DB privilege: TuneVault reads from V$, GV$, DBA_* catalog views and — if EBS is detected — APPS.FND_* views. It requires SELECT_CATALOG_ROLE plus CREATE SESSION. No DBA, no SYSDBA, no ALTER, no INSERT/UPDATE/DELETE on any schema. EBS Ops (bounce, restart) uses your explicitly supplied APPS credentials — never elevated or stored beyond the session.

Compliance posture: See the Trust Center for our current SOC 2 Type II status and compliance roadmap. This security page covers technical controls; the Trust Center covers certifications and third-party assessments.

Built for the
4am call with your CISO.

How the Connection Works

How Credentials Are Handled by Connection Mode

Every Permitted EBS Control Command

Every Action Logged. Immutably.

What We Read, What We Never Touch

Retention Windows

Customer-Run Hardening Scripts

What the lockdown script does

What an Attacker Would Have to Compromise

Residency, Retention & Your Rights

Send this to your security team.

Built for the4am call with your CISO.

How the Connection Works

How Credentials Are Handled by Connection Mode

Every Permitted EBS Control Command

Every Action Logged. Immutably.

What We Read, What We Never Touch

Retention Windows

Customer-Run Hardening Scripts

What the lockdown script does

What an Attacker Would Have to Compromise

Residency, Retention & Your Rights

Send this to your security team.

Built for the
4am call with your CISO.