The Context
Accounting firms handle sensitive client documents - tax returns, bank statements, financial reports, identity documents. These files need to be stored securely, accessible only to the right people, recoverable if accidentally deleted, and auditable for every action taken on them.
Most generic document storage solutions (Google Drive, Dropbox) fail on at least one of these requirements: they lack per-role access isolation at the object level, they delete permanently rather than softly, and they offer limited audit capability.
The Confiance Bizsol DMS was built as an internal MVP to meet these requirements specifically - and is being moved toward a SaaS offering for accounting firms.
The Solution
DMS is a secure document management platform built on AWS S3, with least-privilege IAM policies enforced per role, S3 Versioning used as a recycle bin for recoverable deletion, and full audit logging across every file operation.
The core design principle: every access decision is enforced at the infrastructure layer, not just the application layer.
Key Features
| Feature | Detail |
|---|---|
| Role-Based Object-Level Access | Employees access only the client folders their role permits - enforced at the IAM and API layer |
| Least-Privilege IAM Per Role | Separate IAM policies per role, scoped to specific S3 key prefixes - not broad bucket access |
| Encrypted S3 Buckets | Server-side encryption for all stored documents; client data isolated per bucket or key prefix |
| S3 Versioning as Recycle Bin | Deleted files are soft-deleted (version marked as deleted); authorised users can restore previous versions |
| Full Audit Logging | Every file operation - upload, update, delete, restore - logged with user, timestamp, and action |
| RBAC at API Layer | All access decisions enforced server-side; the frontend cannot bypass role restrictions |
| Client Folder Isolation | Each client's documents live in isolated prefixes; cross-client access is structurally impossible |
Technical Architecture
Stack: Node.js · Express.js · Next.js · AWS S3 · S3 Versioning · IAM · PostgreSQL · RBAC
Key Design Decisions
Least-Privilege IAM Per Role - Not Per User
A common mistake in S3-backed applications is using a single broad IAM role for all application access, then enforcing access control only in application code. If the application layer has a bug, the broad role becomes a security hole.
DMS uses separate IAM policies per role (admin, manager, employee, read-only), each scoped to specific S3 key prefixes. An employee role literally cannot issue API calls to a client prefix they don't own - the IAM policy will deny it before the request reaches S3. Application-layer RBAC is a second enforcement layer, not the only one.
S3 Versioning as a Recycle Bin
When a user "deletes" a document in DMS, the system doesn't call s3.deleteObject(). Instead, it adds a delete marker to the object via S3 Versioning - making the object appear deleted to normal reads, while the previous version remains intact in S3.
Authorised users (admins, managers) can list versioned objects, see deletion markers, and restore any previous version with a single API call. This provides genuine recoverability without building a separate recycle bin storage system - S3 handles the versioning, DMS handles the access control around it.
Audit Logging for Compliance
Every file operation - upload, update, delete, restore - writes an audit log record to PostgreSQL with:
- User ID and role
- Action type
- File key (S3 object path)
- Timestamp
- IP address
- Result (success/failure)
This provides a complete, tamper-evident history of all document operations - essential for accounting firm compliance requirements and incident investigation.
Client Folder Isolation by Design
Client documents are stored under s3://bucket/clients/{client_id}/.... IAM policies and RBAC rules are enforced at the client_id prefix level - an employee assigned to Client A cannot list, read, or write Client B's prefix. This isolation is structural: there's no application-level flag to accidentally misconfigure.
Development Process
- IAM architecture - Designed per-role IAM policies with S3 prefix scoping; tested policy boundaries before building application layer
- S3 bucket configuration - Configured versioning, server-side encryption, and bucket policies for client isolation
- Core file operations API - Built upload, download, update, and soft-delete endpoints with IAM-enforced access
- Recycle bin - Implemented S3 Versioning-based delete/restore flows; built admin UI for viewing and restoring deleted files
- Audit logging - Instrumented all file operations with PostgreSQL audit records; built admin log viewer
- RBAC middleware - Built role-based access enforcement at the Express middleware layer as the second line of defense
Status
DMS is internally tested and in use at Confiance Bizsol. The system is moving toward a public SaaS offering targeting accounting firms - the security architecture (least-privilege IAM, per-client isolation, full audit trail) is a direct match for what regulated industries require from a document management platform.
Impact & Takeaway
DMS makes a specific architectural argument: security enforcement belongs at the infrastructure layer, not just the application layer. IAM policies enforced at the S3 prefix level mean that a bug in application code cannot create a data breach - the infrastructure won't allow cross-client access regardless of what the application asks for.
That philosophy - defense in depth, least privilege at every layer - is what makes this system genuinely suitable for handling sensitive financial documents.
Client documents isolated by IAM. Deletions recoverable via S3 Versioning. Every action audited. Security enforced at the infrastructure layer, not just the app.
Tags: document management system · file management · S3 storage · RBAC · audit logging · data security · access control · enterprise software · compliance management