Sicherheit

Jedes Projekt läuft in einer eigenen Datenbankzelle: ein eigener PostgreSQL-Prozess, ein eigener Speicherbereich, eigene Zugangsdaten und eigene CPU- und Speichergrenzen, die das Betriebssystem durchsetzt. Es gibt keine gemeinsame Datenbank, kein gemeinsames Schema und keine Trennung auf Zeilenebene zwischen zwei Kunden.

Das ist das gesamte Isolationsargument, und es ist bewusst unspektakulär. Ein lauter Nachbar kann deinen Speicher nicht aufbrauchen, weil das Limit nicht geteilt wird. Ein Fehler in der Abfrage eines anderen Mandanten kommt nicht an deine Daten, weil der Prozess sie gar nicht sieht.

Ein K/V-Speicher wird genauso behandelt: eigener Prozess, eigene Speicherobergrenze, eigener Speicherplatz und eigene Zugangsdaten. Er hat keine Netzwerkroute zu deiner Datenbank und keine ins öffentliche Internet – nur der authentifizierte Endpunkt erreicht ihn.

Standardzellen laufen in einem privaten Netzwerk-Namespace mit einem Loopback-Interface und sonst nichts. Eine ausgehende Verbindung ins Internet, zu einer anderen Zelle oder zur Steuerebene können sie nicht öffnen – nicht aufgrund einer Richtlinie, sondern weil es keine Route gibt.

Der Client-Verkehr erreicht die Zelle über einen Socket, den die Routing-Schicht übergibt. Extensions mit ausgehenden Netzwerkaufrufen sind auf Standardzellen genau deshalb nicht verfügbar, und wir sagen lieber nein, als die Grenze still aufzuweichen.

• -TLS auf jeder öffentlichen Verbindung, direkt wie gepoolt, mit pro Region ausgestellten Zertifikaten und geprüften Hostnamen
• -Dashboard, API, CLI und jedes SDK sprechen ausschließlich HTTPS, mit HSTS auf der eigenen Domain
• -Zellspeicher und das Backup-Archiv sind im Ruhezustand verschlüsselt
• -Backups und Write-Ahead-Log-Segmente werden verschlüsselt, bevor sie den Knoten verlassen

Die Routing-Schicht leitet die SCRAM-Authentifizierung von PostgreSQL durchgängig weiter. Dein Datenbankpasswort sieht sie nie, hält sie nie und kann sie nicht rekonstruieren – sie reicht Challenge und Antwort weiter und hält sich heraus.

API-Schlüssel der Organisation werden nur als Hash gespeichert und lassen sich nach der Ausgabe nicht mehr auslesen; verlierst du einen, rotierst du ihn. Projektbezogene Datenbank-Zugangsdaten, die die Steuerebene für Lebenszyklusoperationen hält, sind im Ruhezustand mit einem Schlüssel verschlüsselt, der nicht daneben liegt. Die Anmeldung ist an einen dedizierten Identitätsanbieter delegiert, sodass in unseren Systemen kein Passwort von dir in irgendeiner Form existiert.

• -Laufende Archivierung außerhalb des Knotens: Write-Ahead-Log-Segmente gehen raus, sobald sie entstehen, nicht nach nächtlichem Zeitplan
• -Point-in-Time-Recovery auf einen Moment innerhalb des Aufbewahrungsfensters deines Tarifs, nicht nur auf das letzte Vollbackup
• -Wiederherstellungen werden planmäßig geübt statt als funktionierend angenommen; ein veraltetes oder fehlschlagendes Backup löst einen Alarm aus, auf den wir reagieren
• -Preview-Datenbanken entstehen durch Klonen – eine Wiederherstellung oder eine destruktive Migration zu testen kostet einen Klon, keinen Ausfall
• -Destruktive Operationen in Dashboard, CLI und MCP-Server verlangen vorher einen Wiederherstellungspunkt

Der Produktionszugriff ist auf die Personen beschränkt, die die Plattform betreiben, wird nach Bedarf und nicht nach Rang vergeben und erfordert Mehrfaktor-Authentifizierung. Der Zugriff auf einen Knoten erfolgt ausschließlich über authentifizierte Kanäle; es gibt keine geteilten Logins und keine dauerhaft offene Konsole.

Ein Betreiber liest den Inhalt einer Zelle nur bei von dir angefragtem Support oder bei einem Vorfall, der sich anders nicht lösen lässt. Beides wird protokolliert, und dieses Protokoll würden wir dir auf Nachfrage zeigen.

• -Unbeaufsichtigte Sicherheitsupdates auf jedem Knoten, mit tatsächlich überprüften statt angenommenen Timern
• -Abhängigkeits- und Schwachstellen-Scans in der Pipeline jedes Repositories, für jede Sprache im Stack
• -Dienst-Sandboxing: die Unit jeder Zelle läuft mit minimaler Dateisystemsicht, privatem Netzwerk-Namespace und cgroup-Grenzen
• -Postgres-Minor-Versionen werden als Neustart eingespielt; eine schlafende Zelle bekommt ihr Update kostenlos beim nächsten Aufwachen
• -Sicherheits-Header, eine Content Security Policy und Missbrauchsdrosselung auf den öffentlichen Web-Oberflächen

Knotenzustand, Zellzustand, Backup-Aktualität, Wiederherstellungsprüfung und Ressourcendruck werden laufend abgefragt und alarmieren einen Menschen. Die Verfügbarkeit pro Region wird live auf der Statusseite veröffentlicht.

Wenn etwas kaputtgeht, das dich betrifft, sagen wir es dir per E-Mail und auf der Statusseite, statt zu warten, bis jemand fragt. Erreicht eine Verletzung des Schutzes personenbezogener Daten die Meldeschwelle, gelten die Fristen aus dem Auftragsverarbeitungsvertrag.

CapyDB hat keinen SOC-2-Bericht und kein ISO-27001-Zertifikat und bietet keine HIPAA-Vereinbarung an. Das sagen wir dir lieber hier auf der Sicherheitsseite, als dass du es in einem Fragebogen entdeckst.

Was wir bieten: einen sofort gültigen Auftragsverarbeitungsvertrag ohne Antrag, eine veröffentlichte Position zu Unterauftragsverarbeitern, EU-Datenhaltung für Zellen und Backups und eine gerade Antwort auf jeden Sicherheitsfragebogen. Wenn eine Zertifizierung für deinen Einkauf zwingend ist, sag es – für uns ist das nützlich zu wissen.

Schick sie an die Adresse in unserer security.txt oder schreib uns direkt. Leg genug bei, um sie zu reproduzieren. Wir bestätigen schnell, sagen dir, was wir gefunden haben, und nennen dich als Melder, wenn du das möchtest. Ein bezahltes Bounty-Programm gibt es nicht.

Tests gegen ein eigenes Projekt sind in Ordnung und erwünscht. Tests gegen einen anderen Mandanten oder volumetrische Angriffe auf die Plattform sind es nicht - und das ist das Einzige, was ein Konto ohne vorherige Warnung sperrt.