Serveur staging vs prod ​

Par défaut, lorsque vous créez un compte sur notre site sur https://www.seald.io/create-sdk, votre équipe est créée sur notre serveur de staging (environnement de développement).

Cet environnement est très similaire à nos environnements de production, et vous permet de développer votre projet en toute confiance, en étant certain que vous pourrez ensuite basculer vers un environnement de production sans problème.

Mais, il faut savoir que cet environnement de staging n'est pas adapté pour protéger de véritables données confidentielles, et ne doit donc jamais être utilisé en production, car il comporte certaines différences significatives par rapport à nos environnements de production.

Déploiement de serveurs ​

Nos serveurs de productions sont déployés de façon répliquée, en haute-disponibilité, avec des systèmes de basculement d'un serveur à l'autre pour avoir une plus forte tolérance aux pannes et garantir un niveau de service élevé.

Notre environnement de staging, au contraire, fonctionne sur un serveur unique, sans aucune tolérance aux pannes ni haute-disponibilité des serveurs applicatifs ni de la base de données, et ne garantit aucun niveau de service.

Persistance des données ​

Seald ne garantit pas la persistance des données sur l'environnement de staging.

En effet, nous pourrions être amenés à remettre à zero cet environnement et supprimer des comptes et données sans préavis, que ce soit lors d'une remise en route en cas de panne, pour nettoyer des comptes inutilisées, en cas de violation de nos conditions générales, ou pour toute autre raison.

Au contraire, sur nos environnements de production, nous nous efforçons de suivre les bonnes pratiques de l'industrie, en utilisant des serveurs applicatifs répliqués, des bases de données redondées, de multiples sauvegardes régulières vers des sites distants, etc.

Protection des identités stockées ​

L'environnement de staging étant destiné au développement, il comporte certaines fonctionnalités visant à faciliter les essais.

Par exemple, sur l'environnement de staging, vous pouvez utiliser fake_otp: true pour contourner l'envoi de challenge d'authentification pour la récupération d'une identité stockée en Two-man-rule, ce qui fixe le challenge à 'aaaaaaaa'. Cette fonctionnalité en particulier permettrait à votre serveur, si vous utilisez le stockage d'identité en Two-man-rule, d'usurper l'identité de vos utilisateurs, rendant ainsi inopérant le chiffrement end-to-end. Cette fonctionnalité est bloquée sur les environnements de production.

D'autre part, l'environnement de staging permet aussi de supprimer complètement les identités stockées en Two-man-rule avec full_forget: true, ce qui permettrait au serveur d'écraser l'identité stockée par l'utilisateur et de la remplacer par une autre qu'il maitrise, et ainsi d'effectuer l'équivalent d'une attaque Man-in-the-middle.