¿Cómo garantiza Databasus la seguridad?

Databasus es responsable de datos sensibles:

  • accede a su base de datos;
  • la respalda (es decir, hace una copia de los datos);
  • guarda credenciales para poder acceder a su base de datos de forma regular;
  • guarda las copias de seguridad en su S3 u otros almacenamientos en la nube (si lo activa);

Por lo tanto, la prioridad principal de Databasus es ser seguro y fiable a nivel empresarial.

Databasus garantiza que:

  • los datos sensibles nunca se exponen y siempre están cifrados;
  • las copias de seguridad están cifradas y son inútiles aunque alguien las vea en el almacenamiento en la nube;
  • Databasus ni siquiera recibe acceso de escritura o actualización a la base de datos;
  • todas las acciones se registran y pueden auditarse;

Todos estos pasos protegen sus datos. Ningún sistema es 100% seguro, pero hacemos todo lo posible por acercarnos: incluso en caso de un ataque, nadie podrá corromper sus datos.

Databasus aplica la seguridad en tres niveles:

  1. Cifrado de los datos sensibles;
  2. Cifrado de las copias de seguridad;
  3. Acceso de solo lectura a la base de datos.

Nivel 1: cifrado de los datos sensibles

Internamente, Databasus usa una base de datos PostgreSQL para guardar los datos de conexión, las configuraciones y los ajustes de notificadores y almacenamientos (S3, Google Drive, Dropbox, etc.).

Todo dato sensible se cifra. Por ejemplo:

  • contraseñas
  • tokens
  • webhooks con secretos

Así, en la base de datos Databasus solo guarda hashes o valores cifrados. Para el cifrado se usa el algoritmo AES-256-GCM. Además, a pesar del cifrado, esos valores nunca se exponen a través de la API ni de la interfaz.

La clave secreta usada para el cifrado se guarda en el almacenamiento local (./databasus-data/secret.key por defecto) y no está presente en la propia base de datos. Así, comprometer la base de datos no da acceso a los datos sensibles.

Nivel 2: cifrado de las copias de seguridad

Cada archivo de copia de seguridad se cifra al vuelo durante su creación. Databasus usa el algoritmo de cifrado AES-256-GCM, que garantiza que los datos de la copia no puedan leerse sin la clave de cifrado y que cualquier manipulación se detecte durante el descifrado.

Las copias pasan por esta canalización:

PostgreSQL pg_dump → Compression → Encryption → Cloud Storage

Cada copia recibe su propia clave de cifrado única derivada de:

  • La clave maestra (guardada en ./databasus-data/secret.key)
  • El ID de la copia
  • Una sal aleatoria (única por copia)

Resultado: aunque alguien obtenga acceso a su almacenamiento en la nube (S3, Google Drive, etc.), no podrá leer las copias sin su clave maestra.

Nivel 3: acceso de solo lectura a la base de datos

Databasus aplica el principio de mínimo privilegio: solo necesita acceso de lectura para crear copias de seguridad, nunca de escritura. Esto protege su base de datos de la corrupción de datos, accidental o malintencionada, a través de la herramienta de respaldo.

Antes de aceptar las credenciales de la base de datos, Databasus realiza comprobaciones en tres niveles:

  1. Nivel de rol: verifica que el usuario NO es superusuario y no puede crear roles ni bases de datos
  2. Nivel de base de datos: se asegura de que no hay privilegios CREATE ni TEMP
  3. Nivel de tabla: confirma que no hay ningún permiso de escritura (INSERT, UPDATE, DELETE, TRUNCATE, etc.)

El usuario de la base de datos debe pasar las tres comprobaciones para considerarse de solo lectura. Si se detecta cualquier privilegio de escritura, Databasus le avisará.

Databasus le sugiere crear usuarios de solo lectura con los permisos adecuados:

  • Concede SELECT sobre todas las tablas actuales y futuras
  • Concede USAGE sobre los esquemas (pero no CREATE)
  • Revoca explícitamente todos los privilegios de escritura

Resultado: aunque Databasus se vea comprometido, el servidor sea atacado, la clave secreta sea robada y las credenciales sean descifradas, los atacantes no podrán corromper su base de datos.

🛡️ Ingeniería de seguridad y fiabilidad

Databasus trabaja con datos sensibles, así que prevenir vulnerabilidades, accesos no autorizados y fugas de datos es una preocupación primordial. Invertimos en ello en ambos lados del sistema: en el propio código (comprobaciones de permisos, cifrado, manejo cuidadoso de los secretos) y en la infraestructura que lo rodea (análisis de dependencias, respuesta a CVE, prácticas DevSecOps). La canalización que se describe a continuación se ejecuta automáticamente en cada commit y PR: ninguna capa basta por sí sola, pero juntas reducen la probabilidad de que código vulnerable, dependencias inseguras, imágenes rotas o copias no restaurables lleguen a una versión publicada.

Análisis estático

El análisis estático se ejecuta en varias pasadas independientes. CodeQL escanea todo el código en busca de problemas de seguridad. CodeRabbit revisa cada PR y ejecuta gitleaks para detectar secretos y semgrep para reglas de seguridad en línea. Los Dockerfiles y los flujos de CI tienen reglas adicionales propias (referencias de acciones fijadas, permisos de mínimo privilegio, imágenes base sospechosas), de modo que los patrones inseguros se señalan antes de fusionarse.

Además de estas comprobaciones por PR, Codex Security de OpenAI realiza auditorías periódicas y más profundas de todo el código. Es un programa aparte que detecta problemas arquitectónicos y transversales que los escaneos limitados al momento del PR pasan por alto.

Gestión de dependencias

Dependabot vigila todas nuestras dependencias contra la GitHub Advisory Database y detecta los CVE a los pocos minutos de su publicación. Las actualizaciones pasan por un periodo de espera para que las versiones recién publicadas maduren antes de adoptarlas, una defensa deliberada contra incidentes de paquetes comprometidos como los ataques a la cadena de suministro.

La Dependency Review Action bloquea de plano cualquier PR que introduzca un CVE nuevo de nivel HIGH o CRITICAL.

Endurecimiento de contenedores y CI

  • Las imágenes de contenedor se escanean con Trivy en cada build.
  • Una pasada aparte de Trivy sobre el Dockerfile detecta configuraciones incorrectas antes de que lleguen a una imagen.
  • Todas las GitHub Actions están fijadas a SHA de commit completos en lugar de etiquetas flotantes como @v4 o @main, que han sido un vector de ataque activo en 2025.
  • Los flujos de trabajo usan por defecto permisos de mínimo privilegio y solo los elevan por trabajo cuando es realmente necesario.

Pruebas y verificación

Las rutas críticas están cubiertas por pruebas unitarias y de integración, ejecutadas contra contenedores de bases de datos reales para cada motor y versión mayor compatibles.

La restauración es la ruta que más importa en una herramienta de respaldo, así que la probamos explícitamente: cada PR ejecuta ciclos completos de copia y restauración contra esos mismos contenedores reales, verificando que las copias realmente pueden restaurarse de extremo a extremo, no solo escribirse con éxito.

El resto de la canalización de CI/CD ejecuta lint, comprobación de tipos, la suite de pruebas completa, pruebas de humo de las imágenes y builds multiarquitectura en cada PR. Una versión solo se publica si todo pasa.

Informar de una vulnerabilidad

¿Ha encontrado una vulnerabilidad? Infórmela a través de la pestaña Security de GitHub; consulte SECURITY.md. Los informes de seguridad se atienden con la máxima prioridad.