DEV Community

Cover image for Your Cloud Database is a Security Theater
Ryo Suwito
Ryo Suwito

Posted on

Your Cloud Database is a Security Theater

#programming #devops #ai #webdev

Multi-tenant SaaS storage is broken. Not "needs improvement" broken—fundamentally compromised at the architectural level.

The industry sold you row-level security, tenant IDs in every query, and database encryption at rest. Meanwhile, a single SQL injection or privilege escalation exposes EVERYONE's data. One breach, thousands of victims. This isn't security—it's a ticking time bomb with better marketing.

BSFS (Block Storage File System) takes a different approach: cryptographic isolation at the storage layer.

No shared databases. No trust boundaries inside the application. If you don't have the key, the data doesn't exist.

The Multi-Tenant Trap

Traditional SaaS architecture:

┌─────────────────────────────────┐
│      Application Layer          │
│  (trusted, handles isolation)   │
└─────────────────────────────────┘
           ↓
┌─────────────────────────────────┐
│  Database (ALL tenant data)     │
│  WHERE tenant_id = ?            │
└─────────────────────────────────┘
Enter fullscreen mode Exit fullscreen mode

Single point of failure. Forget one WHERE clause, compromise one API endpoint, exploit one IDOR vulnerability—game over for every tenant.

Database "encryption at rest" is a joke. The encryption keys live in the same system serving your queries. It protects against physically stolen hard drives, not actual attackers with database access.

Copy-on-Write as Atomic Commit

BSFS's most elegant innovation isn't the encryption—it's treating metadata updates as transaction boundaries.


Write process:

  1. Allocate random block addresses
  2. Write new file data to those blocks
  3. Update encrypted Block Allocation Table (BAT)
  4. Mark old blocks free

The BAT update IS the commit point. If your process crashes mid-write, readers still see the old file. New blocks become garbage. No corruption, no partial writes, no "eventually consistent" nonsense.

This is how modern filesystems (BTRFS, ZFS) work—except you're getting it at the application layer for multi-tenant data with cryptographic boundaries between tenants.

// The atomic commit point
bsfs_encrypt_bat(partition_key, bat, encrypted_bat);
fseek(blob_file, partition_offset, SEEK_SET);
fwrite(encrypted_bat, sizeof(bsfs_bat_t), 1, blob_file);
fflush(blob_file);
// Transaction committed. Readers see new file.
Enter fullscreen mode Exit fullscreen mode

Crash before that fwrite? Old file intact. Crash after? New file committed. No in-between state.

Hierarchical Key Derivation

Each tenant gets a master key. Each partition derives its key using HKDF:

Master Key → HKDF(partition_id) → Partition Key
Enter fullscreen mode Exit fullscreen mode


Properties:

  • Master key derives ANY partition key
  • Partition keys CANNOT derive sibling keys
  • Cryptographic isolation, not access control checks

This isn't "encrypted at rest" security theater. Without the partition key, the BAT is random bytes. Without the BAT, file blocks are random unordered chunks. No tenant ID filtering, no permission checks—cryptographic impossibility of cross-tenant access.

Random Block Allocation

BSFS deliberately randomizes block allocation using Fisher-Yates shuffle. Your "users.json" file doesn't sit in nice sequential blocks. It's scattered across the partition at random offsets.

Why sacrifice sequential read performance?

Temporal correlation resistance. In traditional filesystems, files created together live near each other. An attacker analyzing block access patterns can infer file structure, access frequency, relationships—even without decrypting content.

With random allocation, block access patterns reveal nothing about file boundaries or relationships.


SSDs make this viable. Random I/O on modern NVMe drives approaches sequential performance anyway. You're trading legacy HDD optimization patterns for security properties that matter in 2026.

What It's Not

BSFS isn't:

  • A replacement for PostgreSQL
  • A distributed filesystem
  • A key-value store
  • Suitable for millions of tiny files
  • Optimized for range queries

It's a storage primitive for when you need:

  • True tenant isolation
  • Atomic file updates
  • Encrypted metadata
  • Predictable performance
  • SaaS application storage

Think encrypted object storage, not database. Think S3 buckets with cryptographic boundaries, not rows with tenant_id columns.

The API

C Implementation 

uint8_t master_key[32];
bsfs_tenant_t tenant;

bsfs_tenant_init(&tenant, "storage.blob", master_key);
bsfs_write_file(&tenant, file_id, data, size);
bsfs_read_file(&tenant, file_id, &data, &size);
bsfs_delete_file(&tenant, file_id);
bsfs_tenant_cleanup(&tenant);
Enter fullscreen mode Exit fullscreen mode

Python Wrapper 

from bsfs import BSFS, generate_master_key
import uuid

with BSFS('storage.blob', master_key) as fs:
    file_id = uuid.uuid4()
    fs.write_file(file_id, b'confidential data')
    data = fs.read_file(file_id)
    fs.delete_file(file_id)
Enter fullscreen mode Exit fullscreen mode

No ORMs. No query builders. No connection pools. Binary blobs in, binary blobs out. If you need indexing, build it in your application layer with encrypted references.

Current Limits

  • 64 files per partition
  • 512MB max file size (2MB blocks × 256 blocks)
  • Single partition implementation (multi-partition planned)
  • No streaming I/O (full file in memory)
  • Single-threaded


These aren't bugs—they're design constraints for the initial implementation. The architecture supports larger limits; the code just needs extension.

When You Should Care

You should use BSFS if:

  • You're building multi-tenant SaaS
  • Regulatory compliance demands data isolation
  • You've been burned by row-level security bugs
  • You need provable cryptographic boundaries
  • You store files, documents, or blobs per tenant

You shouldn't use BSFS if:

  • You need relational queries
  • You're storing millions of tiny records
  • You need distributed consensus
  • Your threat model doesn't include database compromise

The Economics

Cloud databases charge by IOPS, storage, and compute. BSFS runs on local NVMe, uses raw disk I/O, and encrypts only metadata. You're not paying for:

  • Database connection overhead
  • Query optimizer runtime
  • Replication lag
  • "Serverless" markup
  • Per-tenant database instances

One 2TB NVMe drive handles dozens of tenants with true cryptographic isolation for less than a single RDS instance costs per month.

Most security is social convention enforced by access control lists. BSFS makes cross-tenant data access cryptographically impossible, not just unauthorized.

That's not innovation—that's returning to first principles after decades of compromised shortcuts.

Watch the video where I walk through the implementation, explain the copy-on-write semantics in detail, and demonstrate why encrypted metadata is the actual innovation here.
Youtube: https://youtu.be/pLqC1DblRQE
GitHub: https://github.com/ryo-suwito/bsfs

Top comments (0)