Comment Databasus applique-t-il la sécurité ?

Databasus est responsable de données sensibles :

  • il accède à votre base de données ;
  • il la sauvegarde (c'est-à-dire qu'il fait une copie des données) ;
  • il conserve des identifiants pour pouvoir accéder à votre base régulièrement ;
  • il enregistre les backups dans votre S3 ou d'autres stockages cloud (si vous l'activez) ;

Par conséquent, la priorité absolue de Databasus est d'offrir une sécurité et une fiabilité de niveau entreprise.

Databasus garantit que :

  • les données sensibles ne sont jamais exposées et toujours chiffrées ;
  • les backups sont chiffrés et inutilisables même si quelqu'un les voit dans le stockage cloud ;
  • Databasus ne reçoit même pas d'accès en écriture ou en modification à la base ;
  • toutes les actions sont journalisées et peuvent être auditées ;

Toutes ces mesures protègent vos données. Comme vous le savez, aucun système n'est sûr à 100 %, mais nous faisons de notre mieux pour le rendre aussi sûr que possible. Même en cas de piratage, personne ne pourra corrompre vos données.

Databasus applique la sécurité à trois niveaux :

  1. Chiffrement des données sensibles ;
  2. Chiffrement des sauvegardes ;
  3. Accès en lecture seule à la base de données.

Niveau 1 : chiffrement des données sensibles

En interne, Databasus utilise une base PostgreSQL pour stocker les détails de connexion, les configurations, les paramètres des notificateurs et des stockages (S3, Google Drive, Dropbox, etc.).

Toute donnée sensible est chiffrée. Par exemple :

  • les mots de passe
  • les jetons
  • les webhooks avec secrets

Databasus ne garde donc en base que des hachages ou des valeurs encodées. Le chiffrement utilise l'algorithme AES-256-GCM. De plus, malgré le chiffrement, ces valeurs ne sont jamais exposées via l'API ou l'interface.

La clé secrète utilisée pour le chiffrement est stockée sur le disque local (./databasus-data/secret.key par défaut) et n'est pas présente dans la base elle-même. La compromission de la base ne donne donc pas accès aux données sensibles.

Niveau 2 : chiffrement des sauvegardes

Chaque fichier de backup est chiffré à la volée pendant sa création. Databasus utilise l'algorithme de chiffrement AES-256-GCM, qui garantit que les données de sauvegarde ne peuvent pas être lues sans la clé de chiffrement et que toute altération est détectée au déchiffrement.

Les backups passent par ce pipeline :

PostgreSQL pg_dump → Compression → Encryption → Cloud Storage

Chaque backup reçoit sa propre clé de chiffrement unique, dérivée de :

  • La clé maîtresse (stockée dans ./databasus-data/secret.key)
  • L'ID du backup
  • Un sel aléatoire (unique par backup)

Résultat : même si quelqu'un obtient l'accès à votre stockage cloud (S3, Google Drive, etc.), il ne peut pas lire les backups sans votre clé maîtresse.

Niveau 3 : accès en lecture seule à la base de données

Databasus applique le principe du moindre privilège : il n'a besoin que d'un accès en lecture pour créer les backups, jamais d'un accès en écriture. Cela protège votre base contre toute corruption de données, accidentelle ou malveillante, via l'outil de sauvegarde.

Avant d'accepter des identifiants de base de données, Databasus effectue des contrôles à trois niveaux :

  1. Niveau rôle : vérifie que l'utilisateur n'est PAS superutilisateur et ne peut créer ni rôles ni bases de données
  2. Niveau base : s'assure de l'absence de privilèges CREATE ou TEMP
  3. Niveau table : confirme l'absence totale de permissions d'écriture (INSERT, UPDATE, DELETE, TRUNCATE, etc.)

L'utilisateur de la base doit passer les trois contrôles pour être considéré en lecture seule. Si un privilège d'écriture est détecté, Databasus vous en avertit.

Databasus vous propose de créer des utilisateurs en lecture seule avec les bonnes permissions :

  • Accorde SELECT sur toutes les tables actuelles et futures
  • Accorde USAGE sur les schémas (mais pas CREATE)
  • Révoque explicitement tous les privilèges d'écriture

Résultat : même si Databasus est compromis, le serveur piraté, la clé secrète volée et les identifiants déchiffrés, les attaquants ne peuvent pas corrompre votre base de données.

🛡️ Ingénierie de sécurité et de fiabilité

Databasus manipule des données sensibles, donc la prévention des vulnérabilités, des accès non autorisés et des fuites de données est une préoccupation de premier plan. Nous y investissons des deux côtés du système : dans le code lui-même (contrôles de permissions, chiffrement, gestion soigneuse des secrets) et dans l'infrastructure qui l'entoure (analyse des dépendances, réponse aux CVE, pratiques DevSecOps). Le pipeline ci-dessous s'exécute automatiquement sur chaque commit et PR. Aucune couche ne suffit à elle seule, mais ensemble elles réduisent le risque qu'un code vulnérable, des dépendances dangereuses, des images cassées ou des backups non restaurables atteignent une release.

Analyse statique

L'analyse statique s'exécute en plusieurs passes indépendantes. CodeQL analyse l'ensemble du code à la recherche de problèmes de sécurité. CodeRabbit relit chaque PR et exécute gitleaks pour la détection de secrets et semgrep pour les règles de sécurité directement dans la revue. Les Dockerfiles et les workflows CI ont leurs propres règles supplémentaires (références d'actions épinglées, permissions de moindre privilège, images de base suspectes), si bien que les schémas non sûrs sont signalés avant même d'être fusionnés.

En plus de ces contrôles par PR, Codex Security d'OpenAI effectue des audits réguliers et plus approfondis de tout le code. C'est un programme distinct qui détecte les problèmes architecturaux et transverses que les analyses limitées au moment de la PR laissent passer.

Gestion des dépendances

Dependabot surveille toutes nos dépendances par rapport à la GitHub Advisory Database et fait remonter les CVE quelques minutes après leur publication. Les mises à jour sont appliquées avec un délai, pour laisser aux versions fraîchement publiées le temps de mûrir avant que nous les adoptions : une défense délibérée contre les attaques de la chaîne d'approvisionnement, comme les paquets compromis.

La Dependency Review Action bloque catégoriquement toute PR qui introduit une nouvelle CVE HIGH ou CRITICAL.

Durcissement des conteneurs et de la CI

  • Les images de conteneurs sont analysées avec Trivy à chaque build.
  • Une passe Trivy distincte sur le Dockerfile détecte les erreurs de configuration avant qu'elles n'arrivent dans une image.
  • Toutes les GitHub Actions sont épinglées sur des SHA de commit complets plutôt que sur des tags flottants comme @v4 ou @main, qui ont été un vecteur d'attaque actif en 2025.
  • Les workflows utilisent par défaut des permissions de moindre privilège et ne les élèvent par job que lorsque c'est réellement nécessaire.

Tests et vérification

Les chemins critiques sont couverts par des tests unitaires et d'intégration, exécutés contre de vrais conteneurs de bases de données pour chaque moteur et version majeure pris en charge.

La restauration est le chemin qui compte le plus pour un outil de sauvegarde, donc nous la testons explicitement : chaque PR exécute des cycles complets de sauvegarde puis restauration contre ces mêmes conteneurs réels, en vérifiant que les backups peuvent réellement être restaurés de bout en bout, et pas seulement écrits avec succès.

Le reste du pipeline CI/CD exécute le lint, la vérification de types, la suite de tests complète, des smoke tests d'image et des builds multi-architecture sur chaque PR. Une release ne sort que si tout passe.

Signaler une vulnérabilité

Vous avez trouvé une vulnérabilité ? Signalez-la via l'onglet GitHub Security, voir SECURITY.md. Les rapports de sécurité sont traités en priorité absolue.