Enterprise Security Review

# Built for the
4am call with your CISO.

Share this page with your security team. Architecture, command whitelist, audit schema, and a customer-run lockdown script — our own documentation of how the system works, to support your review.

Security review URL tunevault.app/security
No inbound ports opened on your server
No SSH from TuneVault to your hosts
No plaintext credentials stored — AES-256 encrypted at rest
Control actions are recorded before they execute — a failed audit write refuses the operation
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

## Logged Before It Runs.

The `audit_log` table captures EBS control preview attempts — allowed and rejected — and every EBS, database and OS operation, written before the command is dispatched. No row is ever deleted, and a row's identifying fields are never modified; the outcome fields are filled in once the operation returns.

audit_log — insert-before-execute, no 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 Oracle ADB 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. | REVIEWED

🧅
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 before execution
SQL execution, SSH commands, EBS operations, database operations and agent exec each write to a dedicated audit table — `sql_console_history`, `sql_audit_log`, `ssh_audit`, `audit_log` and `proxy_exec_audit`. Control actions are recorded before the command is dispatched; if that write fails, the operation is refused rather than run unlogged. Once written, a row's identifying fields — who, what, which server, which parameters, when — are never modified; only its outcome fields (result, detail, completion time) are filled in when the operation returns. 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 entirely on Oracle Cloud Infrastructure, with results stored in Oracle 26ai Autonomous Database. Oracle performance metrics collected during a health check are processed and stored on Oracle Cloud. No data is replicated outside Oracle Cloud 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.
🤝
Third-Party Data Sharing
Your Oracle performance metrics, connection details, and health check results are never sold, and no analytics platform, ad network, or data broker receives them. Two AI providers do receive data: Anthropic (Claude) and OpenAI. What is sent is redacted SQL text with bind variable values stripped before transmission — no raw database content, no query results, no business data. Neither provider uses it for model training, per their enterprise API policies.
📅
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 security@tunevault.app. We acknowledge every report within 72 hours. 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 compliance posture, stated plainly. This security page covers the technical controls in depth; the Trust Center summarises them alongside what we have not done, including which certifications we do not hold.

## Send this to your security team.

Everything above is the live state of the system — not a marketing document. The command whitelist is fetched from the database in real time.

tunevault.app/security
📄 Full SQL Whitelist 🔑 Credential Storage ⬇ Download Bundle