A Contractor Needs DB Access for a Week. Open the Port?
Scenario
An external contractor starts Monday morning on a one-week, read-only analysis job against your production PostgreSQL database. The database lives on a private subnet inside the VPC, unreachable from the internet by design. Your company already runs a VPN and a bastion host, but the contractor has an account on neither — and the clock on the engagement is already running.
The Quick Fix on the Table
A teammate proposes the fastest possible path: punch a firewall rule that opens port 5432 to the internet, hand the contractor a strong database password, and delete the rule on Friday when the engagement ends. Five minutes of work, no onboarding paperwork, and the contractor is productive before lunch.
The quick fix is on the table and the room is waiting for your call. Would you sign off on it? Take a position and justify it — out loud or on paper — before revealing the analysis.
Why the Quick Fix Fails
- You expose everyone, not one person. A public 5432 is reachable by the entire internet, and scanners find newly opened database ports within minutes. The "one contractor" door is a door for every credential-stuffing bot on the planet.
- A strong password is a single, phishable factor. Passwords leak, get reused, and get intercepted. With no network boundary left in front of the database, the password becomes your entire security model.
- "Remove it on Friday" is a promise, not a control. Temporary firewall rules have a habit of outliving their reason. If the removal slips — vacation, incident, forgetfulness — the exposure becomes permanent and invisible.
- You lose auditability. Direct internet access gives you no session records, no command trail tied to a person, and no way to answer "what exactly did the contractor touch?" if a question comes later.
- It may be a compliance violation outright. If the database holds personal or customer data, exposing it publicly can breach contractual and regulatory obligations regardless of whether anything bad actually happens.
The interviewer nods: “Fine, the quick fix is off the table. So what exactly would you do — step by step?” Sketch your plan before revealing the approach.
The Right Approach
- Onboard the contractor to the existing access path. Provision a personal VPN profile or a bastion account — the infrastructure already exists, so this is an hour of admin work, not a project.
- Use an SSH tunnel through the bastion if VPN onboarding is slow.
ssh -L 5433:db.internal:5432 contractor@bastiongives the contractor a local endpoint while the database stays private; on AWS the same pattern works keylessly viaaws ssm start-sessionwith port forwarding. - Create a dedicated, least-privilege database account.
CREATE ROLE contractor_ro LOGINwithGRANT SELECTon only the schemas the analysis needs — never the application's credentials, never superuser. - Time-box the account at the database layer too. Set
VALID UNTILon the role for the engagement's end date, so access expires even if every human forgets to clean up. - Restrict the source, not just the credential. Security group rules should allow 5432 only from the bastion or VPN subnet, and
pg_hba.confshould reflect the same — two layers, both narrow. - Turn on logging for the account. Enable connection and query logging (or
pgaudit) scoped to the contractor role, so there is a real answer to "what was accessed" after the engagement. - Consider a replica or masked dataset instead. If the work is analysis rather than operations, pointing the contractor at a read replica — or an export with sensitive columns masked — removes production risk entirely.
Final pushback: “Your plan costs more time and money than the quick fix. Convince me.” How do you defend your position under pressure?
How to Defend It
- "Opening 5432 to the world doesn't give access to one contractor — it gives a login prompt to every scanner on the internet, usually within the hour."
- "The bastion and VPN already exist. Onboarding one person is an hour of work; cleaning up after a database exposure is weeks."
- "A password alone is one leaked secret away from a breach. Network boundary plus scoped credential plus expiry date is three independent controls."
- "With a personal read-only role and audit logging, we can prove afterwards exactly what was accessed. With a shared password on a public port, we can prove nothing."
- "I'm not slowing the contractor down — an SSH tunnel gets them querying today. I'm refusing the version of 'fast' that we might pay for all year."