Security
SigV4 in every form, checksums validated and kept, unknown operations refused, sealed user keys, mutual TLS between nodes, and a metadata account that reaches one database.
An object store's worst failures return success: a tampered body stored, a corrupt read served, an operation routed to the wrong handler. Each of those is refused at a named place here.
Requests
- SigV4 in every form: header, presigned URL and
aws-chunkedstreaming with trailers. The implementation reproduces AWS's published examples, and each example altered in one place is refused. - Anonymous requests reach only what a bucket policy grants everyone, and Block Public Access stops such a policy on every bucket that has not turned it off (see Policies, groups and temporary credentials).
- Unknown operations are refused with
NotImplemented, and an unknown or misplaced parameter before any operation runs (see The S3 surface). - Back-pressure is an answer: past
TESSARIDB_S3_MAX_INFLIGHTrequests a new one gets503 SlowDown.
Integrity
Content-MD5 and the x-amz-checksum-* family are validated before a write is
acknowledged and stored so a read can return them. Underneath, every 1 MiB block of
every object carries a BLAKE3 hash checked on every read.
Keys and access
- Users' access-key secrets are sealed with a key derived per space from
TESSARIDB_S3_IAM_KEY; the metadata never holds one in the clear. A node that loses that key can open no user's key. - Grants are per bucket. A revoked key is refused on every node within the 5-second resolution window.
- One-key upload credentials, issued by a user who may write the bucket, upload exactly one key (a single PUT or every step of a multipart upload of it), expire between 60 seconds and 7 days, and work only while their issuer may still write there.
- Groups carry bucket grants to every member; temporary credentials from
AssumeRoleWithWebIdentitysign with their session token and can be narrowed by a session policy. - Quotas (bytes and objects per bucket) are checked on every write that adds, against the last usage measurement plus the write.
Data at rest
Objects can be sealed under the server's key, a named key or the customer's own key; the keys sit in a vault of their own (see Encryption).
Between nodes and to the database
- The internal shard surface is mutual TLS only, served only to admitted members presenting the certificate for the node they claim to be (see Clusters).
- The server signs in to TessariDB as its own account, an editor of one database
(
DEFINE USER s3 ON s3.meta ROLE editor), never the owner.TESSARIDB_S3_META_CAmakes it verify the node's TLS against a certificate authority you give it.
Reporting
Security reports go to security@tessaridb.com.