Seguridad

Cada proyecto se ejecuta en su propia celda de base de datos: un proceso PostgreSQL dedicado, su propio conjunto de almacenamiento, sus propias credenciales y sus propios límites de CPU y memoria impuestos por el sistema operativo. No hay base de datos compartida, ni esquema compartido, ni partición por filas entre dos clientes.

Ese es todo el argumento de aislamiento, y es deliberadamente poco emocionante. Un vecino ruidoso no puede agotar tu memoria porque el límite no se comparte. Un fallo en la consulta de otro cliente no puede alcanzar tus datos porque el proceso no los ve.

Un almacén K/V recibe el mismo trato: su propio proceso, su propio límite de memoria, su propio almacenamiento y su propia credencial. No tiene ruta de red hacia tu base de datos ni hacia la internet pública — solo lo alcanza el endpoint autenticado.

Las celdas estándar se ejecutan en un espacio de nombres de red privado con una interfaz de loopback y nada más. No pueden abrir una conexión saliente a internet, a otra celda ni al plano de control: no por política, sino porque no existe la ruta.

El tráfico del cliente llega a la celda por un socket que le entrega la capa de enrutamiento. Las extensiones que hacen llamadas de red salientes no están disponibles en las celdas estándar exactamente por eso, y preferimos decir que no antes que aflojar el límite en silencio.

• -TLS en cada conexión pública, directa y con pooler, con certificados emitidos por región y nombres de host verificados
• -El panel, la API, la CLI y todos los SDK hablan solo HTTPS, con HSTS en el dominio propio
• -El almacenamiento de la celda y el archivo de backups están cifrados en reposo
• -Los backups y los segmentos del registro de escritura anticipada se cifran antes de salir del nodo

La capa de enrutamiento retransmite la autenticación SCRAM de PostgreSQL de extremo a extremo. Nunca ve, guarda ni puede reconstruir tu contraseña de base de datos: reenvía el desafío y la respuesta y se aparta.

Las claves de API de la organización se guardan solo como hash y no pueden leerse tras su emisión; si pierdes una, la rotas. Las credenciales de base de datos por proyecto que el plano de control conserva para operaciones de ciclo de vida están cifradas en reposo con una clave que no se guarda junto a ellas. El inicio de sesión está delegado en un proveedor de identidad dedicado, así que en nuestros sistemas no existe ninguna contraseña tuya de ninguna forma.

• -Archivado continuo fuera del nodo: los segmentos del registro de escritura anticipada salen a medida que se producen, no según un plan nocturno
• -Recuperación a un momento concreto dentro de la ventana de retención de tu plan, no solo al último backup completo
• -Las restauraciones se ejercitan de forma programada en lugar de darse por buenas, y un backup obsoleto o fallido dispara una alerta sobre la que actuamos
• -Las bases de preview se crean clonando, así que probar una restauración o una migración destructiva cuesta un clon en lugar de una caída
• -Las operaciones destructivas en el panel, la CLI y el servidor MCP piden antes un punto de restauración

El acceso a producción se limita a quienes operan la plataforma, se concede por necesidad y no por antigüedad, y exige autenticación multifactor. El acceso a un nodo ocurre solo por canales autenticados; no hay credenciales compartidas ni consola permanentemente abierta.

Un operador lee el contenido de una celda solo por un soporte que has pedido tú o por un incidente que no puede resolverse de otro modo. Ambos quedan registrados, y ese registro es lo que te enseñaríamos si lo pidieras.

• -Parcheado de seguridad desatendido en cada nodo, con los temporizadores realmente verificados y no supuestos activos
• -Análisis de dependencias y vulnerabilidades en la canalización de cada repositorio, para cada lenguaje del stack
• -Aislamiento de servicios: la unidad de cada celda se ejecuta con una vista mínima del sistema de archivos, un espacio de nombres de red privado y límites de cgroup
• -Las versiones menores de Postgres se aplican como un reinicio; una celda dormida recibe su actualización gratis al despertar
• -Cabeceras de seguridad, una política de seguridad de contenido y limitación de abuso en las superficies web públicas

El estado de los nodos y de las celdas, la frescura de los backups, la verificación de restauración y la presión de recursos se consultan de forma continua y avisan a una persona. La disponibilidad por región se publica en directo en la página de estado.

Cuando se rompe algo que te afecta, te lo decimos por correo y en la página de estado en lugar de esperar a que preguntes. Si una violación de datos personales alcanza el umbral de notificación, se aplican los plazos del Acuerdo de tratamiento de datos.

CapyDB no tiene informe SOC 2 ni certificado ISO 27001, y no ofrece un acuerdo de socio comercial HIPAA. Preferimos decírtelo en la página de seguridad a que lo descubras en un cuestionario.

Lo que sí ofrecemos: un Acuerdo de tratamiento de datos autoservicio y vigente desde el primer día, una posición publicada sobre subencargados, residencia de datos en la UE para celdas y backups, y una respuesta directa a cualquier cuestionario de seguridad que nos envíes. Si una certificación es requisito indispensable para tu compra, dilo: nos resulta útil saberlo.

Envíala a la dirección de nuestro security.txt o escríbenos directamente. Incluye lo suficiente para reproducirla. Acusamos recibo rápido, te contamos lo que encontramos y te damos crédito si quieres. No hay programa de recompensas pagadas.

Probar contra un proyecto propio está bien y se agradece. Probar contra otro cliente, o lanzar ataques volumétricos contra la plataforma, no lo está, y es lo único que suspende una cuenta sin aviso previo.