TuneVault Security — Enterprise Trust & Architecture Review

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.

🛡

Cloudflare edge in front

All proxy traffic passes through Cloudflare WAF before reaching TuneVault's API. DDoS protection and TLS termination happen at the edge.

🏃

Proxy runs as isolated user

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

📋

No Oracle credentials stored

Oracle username/password are used transiently to open the connection. They are never written to disk or sent to TuneVault servers.

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 (100+ 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 security@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: security@tunevault.app

Connection credentials

Session only

Oracle passwords are used to open the connection and not persisted. 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) ⬇ 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 and *.cloudflare.com for the proxy user.

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.

Built for the
4am call with your CISO.

How the Connection Works

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

Send this to your security team.

Built for the4am call with your CISO.

How the Connection Works

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

Send this to your security team.

Built for the
4am call with your CISO.