Forward this page to your security review team. It contains our architecture, the exact Oracle views we read, what we never do, and a lockdown script you control.
TuneVault never opens an inbound port. The lightweight proxy agent runs on your Oracle server (or EBS app server) and initiates all connections outbound over HTTPS. No VPN, no inbound firewall changes, no inbound SSH. For SSH-SQL query mode, TuneVault opens an outbound SSH connection using credentials you supply — no inbound SSH listener is opened on your server.
Python 3, ~7,500 lines, no obfuscation.
oracle-proxy.py SHA-256: loading…
raw
·
install.sh SHA-256: /install.sh.sha256
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 queries run via OS auth on the proxy host — no Oracle password transmitted | Never |
| SSH-SQL mode (ssh_sqlplus) | SSH key only | Customer-supplied SSH private key stored AES-256-GCM; TuneVault opens outbound SSH to run sqlplus. No Oracle password stored for this mode. | Never |
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.
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.
These are not policies subject to internal override — they are architectural constraints enforced by the read-only Oracle user and proxy design.
Two system privileges cover the core data dictionary and V$ views. One explicit view grant covers the alert log. EBS environments require additional APPS schema grants. All grants are read-only SELECT — no DML, no DDL.
Full setup walkthrough: oracle-setup guide → · Complete SQL query list: security/commands →
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.
| Slug | Label | Category | Command Preview | Risk | Dry-run |
|---|---|---|---|---|---|
|
Loading live whitelist from database...
| |||||
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.
The audit_log table captures every EBS control preview attempt — allowed and rejected — as append-only rows. No row is ever updated or deleted.
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.
allowed=false and a rejection_reason — before returning HTTP 403.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. Credentials still encrypted separately from the DB. | 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 |
TuneVault processes Oracle system metrics — not your business data. Here's the full picture.
DELETE /api/connections/:id to purge all results immediately.DELETE /api/connections/:id purges all associated health check results and credentials.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.
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, Amazon Linux 2/2023, Debian.
tunevault OS user (/sbin/nologin)/opt/tunevault directory to mode 750Bundle includes: tunevault-lockdown.sh + README.md (SOC2/ISO/NIST mapping) + whitelist.json (SHA-256 hashes)
We take security disclosures seriously and respond quickly. If you find something, tell us.
We're an early-stage company. We'll tell you exactly where we stand — not what sounds good on a sales call.
Audit in progress. We use Vanta for continuous control monitoring. Target completion: Q4 2026. Contact us for the current readiness report.
Data subject deletion endpoint live (DELETE /api/connections/:id). All data processed and stored in the US. DPA available on request.
TuneVault reads Oracle system metadata, not application data. We do not process Protected Health Information (PHI) and are out of scope for HIPAA.
Controls aligned to ISO 27001 A.9 (access control), A.12 (operations security), A.13 (communications security). Formal certification planned after SOC 2 completion.
Annual third-party pen test. Most recent report available under NDA to enterprise prospects. Contact security@tunevault.app to request.
The Oracle connecting user holds SELECT ANY DICTIONARY (DBA_ views) and SELECT_CATALOG_ROLE (V$ views), plus an explicit grant on V_$DIAG_ALERT_EXT for alert log access. EBS environments require additional APPS schema grants. No DML, no DDL, no SYS privileges. Exception: agent-only connections (no stored credentials) use OS authentication. The agent runs on your server and queries are still read-only — but the connecting Oracle session has SYSDBA context. We recommend storing tunevault_reader credentials for strict least-privilege operation.
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. |
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