10 posts tagged with "security"

An auditor reviewing your data layer does not want a screenshot. A screenshot is a picture of a number at a moment, detached from the system that produced it, trivially edited, and impossible to verify after the fact. What an auditor actually wants is evidence: a record of what a control did, backed by an observed value, that can be checked against a source of trust without taking anyone's word for it.

That is what a FoundryDB compliance evidence packet is. It is a per-organization document, generated from real platform data, that maps the infrastructure controls we operate to the framework you are being measured against (SOC 2, GDPR Article 30 ROPA, DORA, or the EU AI Act). It is cryptographically signed, stored immutably, and rendered as both machine-verifiable JSON and a human-readable PDF. Anyone holding our published public key can confirm a packet came from the platform and was not altered, with no shared secret and no need to trust the channel it arrived through. This post walks through how that works, from operational data to a signature an auditor can check in their browser.

When an EU financial entity onboards a new cloud provider, the questionnaire arrives with a different vocabulary than the usual security review. It asks for your Register-of-Information entry. It asks for measured recovery times, not a promise that failover exists. It asks who the cloud sub-processor is, what region the data sits in, and how an incident would be recorded. The EU AI Act adds its own column: if you run AI infrastructure, where does the inference happen, what is logged, and what model inventory backs it.

Answering those questions used to mean a human assembling screenshots into a deck and hoping nobody changed a value between the screenshot and the audit. Today we are shipping the next phase of signed compliance evidence: per-organization, cryptographically signed evidence packets for DORA and the EU AI Act, alongside the SOC 2 and GDPR Article 30 ROPA packets we already produce. One API call returns the signed JSON and a clean PDF. Your auditor verifies it themselves against a key we publish.

Every app needs login. Almost nobody wants to build it. So you grab a hosted identity service, ship in an afternoon, and quietly sign a deal nobody prints on the pricing page: your users now live in someone else's database, in someone else's region. Their emails. Their sessions. Their second-factor secrets. All of it sitting inside a control plane you do not run and cannot see into. With Auth0, Clerk, or Cognito, that is the trade. Convenient SDK on top, your users hostage underneath.

FoundryDB App Auth flips it. We run the login service for you: a standard OIDC issuer with hosted, themeable login pages, zero UI to build. But the people signing in stay yours. Their identities, sessions, refresh tokens, and MFA secrets land in a schema inside your own PostgreSQL database, in your region. Our control plane never sees a single one. We run the login. You keep the users.

Your database holds the rows. Your app serves the requests. But almost everything real also produces bytes that are not rows: user uploads, generated PDFs, exports, image thumbnails, model artifacts, documents you want to search later. Until today, holding those bytes meant leaving FoundryDB for a separate object storage account, a separate console, a separate bill, a separate credential model. Your data lived in one place and your blobs lived somewhere else.

Not anymore. FoundryDB Files is live. It is per-org, S3-compatible object storage, built into the platform and hosted in Europe, and it lives right next to the databases and apps you already run here. Provision a bucket in seconds with no VM to size. Reach it from any S3 SDK or tool you already know. Hand out presigned URLs for browser-direct uploads. And, the part we are most excited about, attach a bucket to a hosted app and watch it just work, with credentials the platform mints, scopes, injects, and revokes for you.

App Hosting launched with apps served at https://{name}.foundrydb.com from public images. That covers the demo and the internal tool. It does not cover the two things every real deployment needs: your app on your domain, and your app built from a private image. Both shipped alongside the launch, and both are designed so you never hand a plaintext secret around or click through a certificate wizard.

This post covers the two-certificate model behind custom domains and the write-only credential model behind private registries.

Most teams end up with the same API token wired into half a dozen places: the CI pipeline, a monitoring dashboard, a backup script, a Terraform run, and a one-off cron job someone wrote last year. Every one of those tokens can do everything the platform allows, including deleting your production database. That is a lot of blast radius for a token whose only job is to read a metrics endpoint.

Scoped API tokens fix this. A token can now carry a set of scopes that restrict exactly which resource families it can touch and at what level. A monitoring dashboard gets a token that can only read services. A backup script gets a token that can only manage backups. The token that can delete a database stays in a human's password manager, where it belongs.

Every vendor security questionnaire asks the same questions. Where is the data stored? Is it encrypted at rest? Is it encrypted in transit? When was the last backup? How long do you keep audit logs? Answering them usually means a human logging into a console, taking screenshots, copying values into a spreadsheet, and hoping nobody changed anything between the screenshot and the audit.

The compliance report endpoint replaces that ritual with a single API call. It returns a JSON document describing your data posture across every service in your organization, and it attaches an HMAC-SHA256 signature over that document. An auditor can recompute the signature with a verification key and prove the report came from the platform and was not edited on the way to their desk.

Babelfish supports a subset of SQL Server's security model. Some T-SQL user management commands work as expected, others fail with known limitations, and a few are not supported at all. This post documents every command we tested against a live Babelfish 4.8.0 instance on FoundryDB, with exact results.

The practical takeaway: manage your database users through the FoundryDB API, which handles user creation at the PostgreSQL level and avoids the current Babelfish limitations entirely.

OpenSearch's security plugin provides index-level permissions, field-level exclusions, and field masking out of the box. All of these are configurable through the Security REST API, which means you can automate role provisioning in CI/CD pipelines without touching the Dashboards UI. This post documents two concrete access control scenarios tested on a live OpenSearch 2.19.1 cluster managed by FoundryDB, with real HTTP responses showing enforcement in action.

All commands use YOUR_OPENSEARCH_HOST and YOUR_PASSWORD as placeholders. Note that the Security API uses the _plugins/_security prefix.

When we started building FoundryDB, one of the first decisions was where to run the infrastructure. The answer shaped everything that followed: we chose to build exclusively on European cloud providers, starting with UpCloud, a Finnish infrastructure company operating under EU law.

This was not a marketing decision. It was a legal and architectural one. If you store customer data in databases, the jurisdiction of the infrastructure underneath those databases determines what legal regime governs access to that data. For many organizations in Europe, this distinction is no longer optional.