Securing and controlling access to your object storage

Encryption at rest

Server-side encryption means the storage platform encrypts your data as it's written and decrypts it again as it's read back, without you having to encrypt anything on your end first. It protects the data sitting on disk: if a drive were somehow removed or accessed outside the normal API path, the contents would be unreadable without the encryption key. Most S3-compatible object storage platforms apply this by default, transparently, so ordinary reads and writes through the S3 API don't change at all.

A variant worth knowing about is customer-provided-key encryption, sometimes called SSE-C. Instead of relying entirely on the provider's own key management, you supply your own encryption key with each request, and the platform uses that key rather than one it manages internally. That gives you more direct control over the key material, but it comes with a real responsibility: if you lose your key, the provider generally can't recover the data for you, because they never held a copy of it.

Access control: policies, ACLs and pre-signed URLs

Encryption protects data at rest; access control decides who's allowed to read, write, or list it in the first place. On S3-compatible platforms this usually takes two forms. Bucket policies and object-level access control lists (ACLs) define permissions declaratively, who or what can perform which actions against a bucket or an individual object, and they're the mechanism you'd use to keep a bucket private by default or open specific parts of it deliberately.

Pre-signed URLs solve a narrower, common problem: letting someone outside your organisation download or upload a single object without handing them your actual credentials. A pre-signed URL grants temporary, time-limited access to one specific object. It expires on its own, so there's no standing credential to revoke afterwards, which makes it a convenient way to share one file, an invoice, an export, an installer, without opening up broader account access.

Legal hold vs. Object Lock: two different locks

It's easy to conflate these because they both stop data from being changed, but they're not the same mechanism.

A legal hold, as a general concept on S3-compatible platforms, is an indefinite lock placed on an individual object. It overrides whatever retention or lifecycle rule would otherwise apply to that object, and it stays in force until someone with the right permissions explicitly removes it, typically for a compliance or e-discovery reason rather than a storage-management one.

Worldstream's Object Lock feature is a different thing. It's a write-once (WORM) setting applied at the bucket level, turned on when you create the bucket, and it cannot be disabled again once the bucket exists. That makes it a decision you take upfront, per bucket, rather than something you switch on later. If your use case needs per-object legal holds specifically, rather than a bucket-wide write-once guarantee set at creation time, check with Worldstream support first.