Sécurité

1. Vue d’ensemble

• Tout le trafic vers Telbase (site web, tableau de bord, API, CLI) passe par HTTPS.
• Les variables d’environnement d’une application sont détenues par son hébergeur. Les secrets que Telbase conserve lui-même sont chiffrés en AES-256-GCM avant d’être stockés.
• Connexion avec Google, GitHub, ou par e-mail et mot de passe. Les mots de passe ne sont conservés que sous forme de hachages scrypt.
• La connexion de la CLI passe par une procédure d’autorisation de l’appareil : vous confirmez un code, puis cliquez sur « Authorize » dans votre navigateur, après vous être connecté.
• Les organisations disposent des rôles owner, admin, developer et viewer.
• Les applications et les bases de données fonctionnent sur Vercel, Google Cloud, Neon et Turso, dans les environnements isolés de ces fournisseurs.

2. Ce que nous n’avons pas encore

Nous préférons que vous en teniez compte dès maintenant plutôt que de le découvrir plus tard.

• Révocation immédiate des jetons d’accès. La déconnexion révoque votre session sur le serveur, si bien que le jeton de rafraîchissement cesse aussitôt de fonctionner ; un jeton d’accès déjà émis reste valide jusqu’à son expiration, au plus 12 heures plus tard.
• Révocation de la session de déploiement d’un agent. La session avec laquelle un agent déploie (telbase session) dure jusqu’à 24 heures. Se déconnecter, réinitialiser son mot de passe ou retirer un membre de l’organisation n’y met pas encore fin ; elle prend fin à son expiration.
• Sauvegardes managées des bases de données. Telbase ne crée, ne liste ni ne restaure de sauvegardes de bases de données, quelle que soit l’offre. Exportez vous-même vos données (voir DatabasesENen anglais).
• Contrôles bloquants des dépendances et analyse statique dans la CI. Notre CI exécute les vérifications de types, le lint, les tests unitaires et un rapport d’audit des dépendances. Cet audit ne bloque pas encore une fusion, et nous n’effectuons aucune analyse statique (SAST).
• Certifications propres à Telbase. Nous ne détenons aucune attestation SOC 2, ISO 27001, HIPAA ou PCI qui nous soit propre. Voir Conformité.
• Connexion avec Microsoft. Elle apparaît dans certains documents, mais n’est pas activée.

3. Infrastructure

3.1 Où tout fonctionne

• Plan de contrôle, broker de déploiement et base de métadonnées : Google Cloud (Cloud Run et Cloud SQL, une région aux États-Unis).
• Frameworks web (Next.js, Vite, Astro, statique, Node) : Vercel.
• Conteneurs, Python, Go et autres environnements d’exécution : Google Cloud Run, compilés avec Google Cloud Build.
• PostgreSQL : Neon. SQLite : Turso.
• DNS, CDN et domaines personnalisés : Cloudflare.

Chaque fournisseur chiffre les données au repos et en transit sur sa propre infrastructure et détient ses propres certifications (listées dans Conformité).

3.2 Réseau

• Toutes les connexions au plan de contrôle et aux API des fournisseurs utilisent TLS.
• Les connexions aux bases de données fournies à vos applications utilisent TLS.
• L’origine qui héberge le plan de contrôle est joignable directement comme via Cloudflare ; il est prévu de restreindre l’accès entrant à Cloudflare.

4. Vos données et vos secrets

4.1 Variables d’environnement et chaînes de connexion

• Les variables d’environnement d’une application se trouvent chez son hébergeur (Vercel ou Google Cloud Run). Telbase les lit et les modifie là-bas lorsque vous utilisez telbase env, le tableau de bord ou la session de déploiement d’un agent. Les owners, admins et developers peuvent les lire et les modifier ; les viewers n’en voient que les noms. Quiconque peut déployer une application peut lire ses variables par l’application elle-même : elles ne sont donc pas cachées aux developers. Les listes affichent par défaut des valeurs masquées.
• Les chaînes de connexion aux bases de données et les clés de stockage sont affichées par la CLI le temps d’une commande, ou transmises directement à l’hébergeur ; Telbase ne conserve pas la chaîne de connexion à la base de données d’une application.
• Les secrets que Telbase conserve lui-même sont chiffrés en AES-256-GCM avant d’être écrits dans notre base de données.
• Les variables NEXT_PUBLIC_* et autres variables publiques de compilation sont, par conception, intégrées à votre bundle client.

4.2 Votre code source

• Votre agent de code déploie avec la CLI Vercel ou gcloud, exécutée via le broker de Telbase, qui transmet l’envoi à Vercel ou à Google Cloud. Telbase ne conserve pas de copie de votre code source.
• L’application GitHub de Telbase ne lit que les dépôts auxquels vous lui avez donné accès. Telbase ne pousse jamais de code dans vos dépôts.

4.3 Suppression

Supprimer un projet supprime ses ressources chez l’hébergeur, ses variables d’environnement, ses enregistrements de déploiement et sa base de données. Voir la Politique de confidentialité pour les durées de conservation.

5. Authentification

5.1 Connexion

• Google et GitHub via OAuth 2.0. La connexion est refusée si le fournisseur n’indique pas l’adresse e-mail comme vérifiée.
• E-mail et mot de passe. Les mots de passe sont hachés avec scrypt ; nous ne conservons jamais le mot de passe lui-même. L’adresse e-mail doit être vérifiée avant que la connexion par mot de passe fonctionne.

5.2 Sessions

• Les sessions sont des JSON Web Tokens : un jeton d’accès valide 12 heures et un jeton de rafraîchissement valide 30 jours. Chaque jeton de rafraîchissement actif a un enregistrement côté serveur.
• Les jetons de rafraîchissement changent à chaque utilisation. Si un jeton déjà remplacé est présenté de nouveau, toute la session est révoquée, car l’une des deux copies n’était pas la vôtre.
• La déconnexion révoque la session sur le serveur ; le jeton de rafraîchissement cesse immédiatement de fonctionner et le jeton d’accès expire dans les 12 heures (voir la section 2). Réinitialiser votre mot de passe révoque toutes les sessions de connexion de votre compte. La session de déploiement d’un agent est distincte et ne prend fin qu’à son expiration, au plus 24 heures plus tard (voir la section 2).

5.3 CLI

• telbase auth login affiche un code à usage unique dans votre terminal et ouvre le tableau de bord.
• Vous devez être connecté, voir le même code sur la page et cliquer sur Authorize. Vous pouvez aussi cliquer sur Deny. Ouvrir le lien ou se connecter ne suffit pas, à soi seul, à connecter un terminal.
• Les demandes expirent au bout de 15 minutes, ne servent qu’une fois, et leur interrogation est limitée en débit.

5.4 Protection contre les abus

• Les tentatives de connexion et d’inscription sont limitées en débit par adresse d’origine ; les e-mails de réinitialisation de mot de passe et de vérification sont limités par adresse e-mail.
• Les comparaisons de jetons et de signatures s’effectuent en temps constant.

5.5 Accès à vos applications déployées

Vous pouvez restreindre l’accès à une application à certaines adresses e-mail ou à un domaine de messagerie (telbase access). Cette restriction s’applique en amont de votre application via Cloudflare Access, qui gère aussi les sessions de ces visiteurs.

6. Contrôle des accès

6.1 Rôles

Les contrôles de rôle s’appliquent aux points d’accès des projets, des déploiements, des environnements, des bases de données, des domaines, de l’équipe, du stockage, de la facturation, de GitHub, de Slack et des tâches planifiées, chacun selon sa propre autorisation. La session de déploiement d’un agent est délivrée aux owners, admins et developers et agit sur toutes les applications de l’organisation : elle déploie, lit et modifie les variables d’environnement, et lit les journaux. Par elle, un agent ne peut ni supprimer des applications, des bases de données ou du stockage de fichiers, ni modifier les paramètres des projets. Les viewers ne peuvent rien modifier.

6.2 Isolation entre clients

Chaque projet, service, variable d’environnement, base de données et installation GitHub est rattaché à une seule organisation, et chaque requête API est résolue dans l’organisation de l’appelant avant tout contact avec un fournisseur.

6.3 GitHub

• L’application GitHub de Telbase lit le contenu des dépôts auxquels vous lui donnez accès et reçoit leurs événements de push.
• Les installations ne sont rattachées à votre organisation que par le parcours Connect du tableau de bord.
• Telbase n’écrit jamais dans vos dépôts.

7. Sécurité des applications et des compilations

7.1 Notre façon de développer

• Chaque push et chaque pull request exécutent la vérification des types, le lint et les suites de tests unitaires dans GitHub Actions.
• Nous tenons à jour un audit de sécurité indépendant de la plateforme et suivons ses constats jusqu’à leur résolution.
• Chaque push produit aussi un rapport d’audit des dépendances (npm audit) dans la CI. Il ne bloque pas encore une fusion, et nous n’effectuons pas d’analyse statique (SAST).

7.2 Compilations

• Les compilations s’exécutent sur Vercel ou Google Cloud Build, dans l’environnement de compilation isolé et éphémère du fournisseur.
• Vos fichiers parviennent à la compilation comme décrit à la section 4.2.
• Les variables d’environnement sont disponibles pendant la compilation si nécessaire (par exemple pour les migrations de base de données).

7.3 Exécution

• Les applications s’exécutent dans l’environnement isolé du fournisseur (fonctions et edge Vercel, ou conteneurs Cloud Run), avec les limites de ressources du fournisseur.
• Telbase enregistre si chaque déploiement a été mis en ligne ou a échoué, tel que Vercel ou Cloud Run le signale.

8. Surveillance et journalisation

• Les erreurs du plan de contrôle sont signalées à Sentry.
• Un journal d’audit enregistre les connexions, les modifications de variables d’environnement faites depuis le tableau de bord, la CLI ou l’API, les opérations sur les bases de données et le stockage, les modifications de domaines, d’équipe et de facturation, les annulations et retours en arrière de déploiements, et les actions d’administration. Les déploiements eux-mêmes figurent dans l’historique de déploiement de chaque application ; les modifications de variables d’environnement qu’un agent fait par sa session de déploiement ne sont pour l’instant enregistrées que dans les journaux internes de Telbase. Les valeurs des secrets ne sont jamais écrites ni dans l’un ni dans l’autre.
• Les journaux des applications sont ceux de l’hébergeur ; ils s’affichent dans le tableau de bord et dans la CLI.
• Nous ne publions pas encore de page d’état ni d’engagements de conservation des journaux.

9. Réponse aux incidents

Nous sommes une petite équipe et ne publions pas encore d’objectifs de délai de réponse. Ce à quoi nous nous engageons :

• Si nous confirmons un incident de sécurité touchant vos données, nous écrirons aux clients concernés dans les 72 heures suivant la confirmation, en précisant ce qui a été touché et ce que vous devez faire.
• Nous contiendrons l’incident, corrigerons sa cause et publierons une analyse post-incident à l’intention des clients concernés.

10. Signalement des vulnérabilités

10.1 Signaler un problème de sécurité

Nous apprécions les signalements responsables. Si vous trouvez un problème de sécurité, écrivez à [email protected] avec une description, les étapes pour le reproduire, l’impact que vous lui attribuez et le moyen de vous joindre.

10.2 Notre engagement

• Nous accuserons réception de votre signalement sous deux jours ouvrés.
• Nous vous tiendrons informé pendant l’analyse et la correction.
• Nous n’engagerons pas de poursuites à votre encontre pour des recherches menées de bonne foi.
• Nous vous citerons si vous le souhaitez.

10.3 Périmètre

Dans le périmètre : telbase.ai et *.telbase.ai, la CLI Telbase et les API Telbase.

Hors périmètre : les applications des clients déployées sur Telbase (à signaler à leurs propriétaires), l’ingénierie sociale, le déni de service et les attaques physiques.

11. Conformité

11.1 Certifications des fournisseurs

Nos fournisseurs d’infrastructure détiennent, pour leur propre infrastructure :

• Vercel : SOC 2 Type II, ISO 27001
• Google Cloud Platform : SOC 2 Type II, ISO 27001, éligible HIPAA, FedRAMP
• Neon : SOC 2 Type II
• Cloudflare : SOC 2, ISO 27001, PCI DSS

11.2 Telbase lui-même

Telbase ne détient pas de certification SOC 2, ISO 27001, HIPAA ou PCI DSS. La certification d’un fournisseur ne s’étend pas au plan de contrôle propre à Telbase.

11.3 Protection des données

Nous traitons les données personnelles conformément au RGPD et au CCPA, comme décrit dans notre Politique de confidentialité.

12. Contact