Sécurité

La décision de sécurité la plus importante de Kanbanly, c'est l'endroit où les droits sont vérifiés. Ils ne le sont ni dans l'écran, ni dans le code qui interroge la base : ils le sont dans la base de données elle-même, avec des politiques de sécurité au niveau de la ligne.

La différence est énorme et mérite d'être comprise. Si les droits sont vérifiés dans les requêtes, il faut y penser dans chacune d'elles : sur la centaine que cette application exécute, en oublier une n'est qu'une question de temps, et celle qu'on oublie ne produira aucune erreur — elle montrera des données qu'elle ne devait pas, et on s'en apercevra quand quelqu'un se plaindra. Avec des politiques dans la base, la vérification s'applique à toutes les lectures par définition, sans qu'aucune requête ait à y penser. Une requête mal écrite renvoie moins que prévu, jamais plus.

Sur cette base reposent les rôles de tableau — administrer, modifier, commenter, observer —, la visibilité des espaces de travail, l'accès des invités à un tableau isolé et les champs de votre profil que chacun peut voir.

Les mots de passe sont gardés par le système d'authentification de Supabase, chiffrés avec des fonctions de dérivation prévues pour cela. Kanbanly ne conserve pas de mots de passe dans sa propre base, et ni le code de l'application ni celui qui l'administre ne peuvent lire le vôtre. Quand vous l'oubliez, nous ne pouvons pas vous le dire : nous pouvons seulement vous donner un moyen d'en mettre un autre.

Vous pouvez aussi vous connecter avec Google, auquel cas le mot de passe n'existe même pas de notre côté : c'est Google qui vous identifie et nous en recevons la confirmation.

La récupération de mot de passe passe par un lien envoyé à votre courriel, avec une expiration. Tant qu'une récupération est à moitié faite, l'application vous ramène la terminer plutôt que de vous laisser à mi-chemin avec une session dans un état bizarre.

Le numéro de votre carte, sa date d'expiration et son code de sécurité n'arrivent jamais jusqu'à Kanbanly. Vous les saisissez sur le formulaire de Wompi, qui les traite et qui est soumis aux normes de l'industrie des moyens de paiement.

En retour nous ne gardons que le nécessaire pour pouvoir vous montrer ce qui a été prélevé et avec quoi : l'identifiant de la transaction, le montant, la devise, l'état, la marque de la carte et ses quatre derniers chiffres. Avec cela, on ne peut rien prélever.

Chaque prélèvement porte une référence unique que nous produisons, et c'est cette unicité qui empêche de facturer deux fois la même période. Les avis que la passerelle nous envoie quand un prélèvement change d'état sont signés, et la signature est vérifiée avant d'en tenir compte : sans cette vérification, quiconque connaîtrait l'adresse de l'avis pourrait déclarer approuvé un paiement qui n'a jamais eu lieu.

Tout le trafic entre votre navigateur et Kanbanly est chiffré en HTTPS, sans exception et sans possibilité de se connecter autrement. Il en va de même du trafic entre l'application et la base, et entre l'application et les prestataires de courriel et de paiement.

Les données stockées sont chiffrées au repos par l'infrastructure de la base et du stockage de fichiers.

Les pièces jointes des cartes sont conservées dans un stockage distinct de la base, et la liste des pièces jointes d'une carte est protégée par les mêmes règles d'accès que la carte : qui ne peut pas ouvrir la carte ne voit pas ses pièces jointes.

Il y a une limite de taille par fichier, et en plus un plafond par formule : un fichier qui dépasse le plafond de votre formule est refusé et supprimé du stockage plutôt que laissé là à occuper de la place sans que personne y revienne.

Cette section est inhabituelle sur une page de sécurité, et elle est là exprès : nous pensons que dire quelles failles nous avons trouvées et comment nous les avons refermées en dit plus long sur la sécurité d'un produit qu'une liste d'adjectifs.

Les fonctions qui peuvent produire un courriel depuis un compte connecté ont des plafonds par personne et par fenêtre de temps, contrôlés dans la base et pas seulement à l'écran. Sans eux, un formulaire qui envoie du courriel est un robinet ouvert : quelqu'un de mal intentionné remplit la boîte de l'assistance et, au passage, épuise le quota du prestataire pour tout le reste de ce que Kanbanly envoie.

Les fenêtres sont glissantes et ne se réinitialisent pas à minuit, précisément pour qu'on ne puisse pas dépenser deux quotas entiers à deux minutes d'intervalle.

Chaque changement dans la base est une migration numérotée, avec son explication écrite du pourquoi et de la faille précise qu'elle corrige, et avec des tests qui s'exécutent sur un vrai PostgreSQL : on vérifie que celui qui ne doit pas voir quelque chose ne le voit pas, et pas seulement que celui qui doit le voir le voit. Ne vérifier que la bonne moitié, c'est ce qui laisse passer la moitié de la faille.

Le code est accompagné de tests automatiques exécutés avant toute publication. Plusieurs d'entre eux sont des gardiens : ils ne vérifient pas que quelque chose fonctionne, mais qu'une règle n'a pas été enfreinte sans que personne s'en aperçoive. Chaque gardien est cassé exprès au moment de l'écrire, pour confirmer qu'il se déclenche.

Les clés d'accès aux prestataires vivent dans des variables d'environnement du serveur et ne voyagent pas jusqu'au navigateur. Celles qui doivent être publiques le sont par conception, et derrière elles se tiennent les politiques de la base qui empêchent d'en faire un usage indu.

Dites-le-nous. Vous n'avez pas besoin de savoir l'expliquer en termes techniques ni de prouver quoi que ce soit : si quelque chose vous a laissé voir ce que vous n'auriez pas dû, ou vous a simplement paru bizarre, nous voulons le savoir.

Écrivez-nous par le canal d'assistance de l'application et décrivez-la avec autant de détails que possible : ce que vous avez fait, ce que vous attendiez et ce qui s'est passé à la place. Si vous pouvez joindre une capture d'écran, c'est encore mieux.

Nous vous demandons deux choses en échange : nous laisser un délai raisonnable pour corriger avant d'en parler en public, et ne pas accéder aux données d'autres personnes au-delà du minimum nécessaire pour confirmer que la faille existe. Nous n'irons pas après quelqu'un qui signale de bonne foi.

Être honnête sur les limites fait partie de l'exercice. Kanbanly ne propose pas encore l'authentification à deux facteurs, ni l'authentification unique d'entreprise, ni de certifications de conformité auditées par des tiers. Il n'y a pas de programme de primes aux failles.

Si l'un de ces points est indispensable pour votre organisation, dites-le-nous par l'Aide : savoir qui en a besoin et pour quoi faire, c'est ce qui décide de l'ordre dans lequel les choses se font.