Secure File Vault — end-to-end encrypted drops for a fabrication studio

The problem

A design-and-fabrication studio was managing sensitive client work over email. Design files, fabrication drawings, quotes — sent as attachments between designers, the fabrication team, and sales.

Two failure modes were happening regularly:

• Version confusion. By week two of a project, Kitchen_Final.pdf, Kitchen_Final_v2.pdf, and Kitchen_Final_v2_REALLY_FINAL.pdf were all floating in different inboxes. Fabrication built against the wrong one twice in six months.
• Preview leaks. Attachments forwarded to third parties (sub-contractors, image compressors, “let me check this on my phone”) meant proprietary designs reached places they shouldn't have.

They needed a real vault. One place per project, locked by role, with an audit trail that could prove exactly who saw what and when.

Constraints

• Role-scoped by drawer, not by folder. Designers, Fabrication, Sales, and the Owner each needed to see a different slice of every project. Not “same folder, filtered view” — separate drawers, so nobody could accidentally screenshot something they weren't authorized to see.
• Time-boxed access, not permanent. Contractors shouldn't retain access forever. Keys needed to expire: 24h for external reviewers, 48h for extended contract work, or automatically at project close.
• Encryption that actually means something. Not “encrypted at rest in S3” (which every S3 bucket is by default). Application-layer encryption where the vault operator couldn't read files even if they wanted to.
• Audit-ready. Every action logged in a way that can't be quietly edited later.

What I shipped

• Role-based drawers. Designers see design files. Fabrication sees fabrication drawings. Sales sees quotes and contracts. Owner sees everything. No cross-visibility unless explicitly granted.
• Owner-approved keys with expiry. Any access grant requires the Owner to approve. Keys are issued with a hard expiry (24h / 48h / at-project-close) enforced server-side.
• Upload → quarantine → scan → store pipeline. Files land in a quarantine bucket first. They get virus-scanned (ClamAV) and MIME-verified (files claiming to be PDFs but containing executables get rejected). Only after passing both do they get encrypted and moved into the vault.
• Hash-chained audit log. Every action writes a log entry whose hash includes the previous entry's hash. If anyone tries to quietly edit the log, the chain breaks — visibly and irreversibly.
• Watermarked downloads. Any file downloaded gets a per-download watermark (username + timestamp + IP hash) embedded in the PDF. If a preview leaks, the source is provable.
• End-to-end encryption via AWS KMS envelope encryption — each file encrypted with a unique data key, and the data key encrypted with a project-scoped KMS key. The vault server never sees plaintext.

The hard parts

Getting encryption right without wrecking usability. End-to-end encryption is easy to say, hard to make usable. The classic failure mode is “user forgets password → files lost forever.” I solved it with owner-held recovery keys stored in KMS. Recovery is possible via an owner-approval flow, but not via a support ticket. The studio owner has real power; support staff (none by design) don't.

The hash-chained audit log. Each entry stores prev_hash — the SHA-256 of the previous entry. Every hour a background job publishes the latest chain head to a separate KMS-signed record. Editing any historical entry breaks the chain from that point forward, and the tampered chain won't match the last signed head.

MIME confusion attacks. Users claim to upload PDFs, sometimes it's actually an executable renamed to .pdf (accident or attack). I inspect the file's actual magic bytes, not the extension or client-provided MIME type. Mismatches get rejected at the quarantine stage.

AWS WAF for a public-facing internal tool. The vault is only used internally but is publicly reachable (staff work from anywhere). WAF handles the OWASP baseline — rate limits, geo-blocking to allowed regions, bot detection — before requests even reach the app.

Result

Encrypted end-to-end · audit-ready. Emails stopped being the file-transfer mechanism for sensitive design work. Version confusion dropped to zero — there's exactly one place a file lives, and its version history is visible.

The audit log has been useful exactly once: an ex-contractor was suspected of reusing designs elsewhere; the log showed no download post-termination — cleared them. That single use paid for the whole system.

What I'd do differently

Should've invested earlier in per-file preview generation. Right now, viewing a file requires downloading it (watermarked). A server-side preview generator that renders sanitized previews without requiring download would be safer and faster for casual viewing.

Takeaway

Security-critical internal tools are usually built as “secure enough” — role-based auth on top of a normal file store, with the encryption story being whatever AWS gives you by default. Fine for most companies. For clients with genuinely proprietary designs, that's not enough. Application-layer encryption the operator can't undo has a real engineering cost, but the trust it earns is disproportionate.