Dans le cadre de la série « Security Masterclass » Aikido, Mackenzie Jackson s'est entretenu avec Bill Harmer (CISO, Supabase) et Etienne Stalmans (ingénieur sécurité, Supabase) afin d'explorer la manière dont Supabase aborde la sécurité comme une partie intégrante de la conception, et non comme un élément à ajouter après coup.
De la sécurité au niveau des lignes (RLS) aux risques liés au codage assisté par l'IA, la discussion a porté sur les éléments nécessaires pour développer rapidement tout en garantissant la sécurité.
La sécurité commence par les données
La philosophie de Supabase commence avec les données elles-mêmes.
« Nous avons conçu Supabase du point de vue d'un développeur. Tout commence par les données. Pourquoi créer des couches secondaires alors que vous pouvez tout contrôler à partir d'un seul endroit ? » - Bill Harmer, CISO Supabase
Au lieu de répartir la logique de sécurité entre les différents services, Supabase la rapproche de l'endroit où se trouvent les données. Plus le contrôle est proche, moins il y a de risques que les choses tournent mal.
Construire à partir des principes fondamentaux
Pour Étienne, cette approche change la façon dont les développeurs envisagent la création de logiciels.
« Lorsque vous rapprochez la sécurité de vos données, vous commencez à y réfléchir à partir des principes fondamentaux. Une fois que vous avez compris cela, vous accélérez le développement et restez confiant quant à la sécurité. » - Etienne Stalmans, ingénieur sécurité chez Supabase
En intégrant la propriété et l'accès aux données dans la conception des applications, les équipes éliminent les incertitudes liées aux systèmes d'autorisation à plusieurs niveaux.
Anonyme ou authentifié
Supabase simplifie le contrôle d'accès. Les utilisateurs sont soit anonymes, soit authentifiés, sans intermédiaire.
« Toutes les mises à jour des données doivent être consignées : qui a fait quoi, quand et pourquoi. Les utilisateurs anonymes ont un accès limité. Les utilisateurs authentifiés obtiennent exactement ce dont ils ont besoin, et rien de plus. » - Bill Harmer, CISO Supabase
Etienne l'a démontré pendant la session à l'aide d'une application de partage de recettes en direct.
Les recettes publiques étaient visibles par tous. Les recettes privées n'étaient visibles que par leurs propriétaires ou par certains utilisateurs avec lesquels elles avaient été partagées.
Quelques lignes de SQL, soutenues par Row Level Security, ont permis de gérer l'ensemble du modèle.
La sécurité au niveau des lignes n'est pas négociable.
RLS définit qui peut voir ou modifier quelles lignes de données. C'est l'une des fonctionnalités les plus puissantes de Postgres et l'une des plus faciles à négliger.
« Il suffit d'un seul contrôle manquant pour que tout soit compromis. » - Etienne Stalmans, ingénieur sécurité chez Supabase
Etienne a donné un exemple où une politique générée par l'IA a accidentellement renvoyé tous les enregistrements d'un tableau parce qu'elle avait ignoré une condition.
La solution consistait en une seule correction de la requête, une ligne qui comblait une faille de sécurité majeure.
Bill l'a résumé simplement :
« Nous voulons que la sécurité soit aussi proche que possible des données. Plus elle est proche, moins il y a de place pour l'erreur. » - Bill Harmer, CISO Supabase
Tester vos politiques avec pgTAP
La sécurité ne s'arrête pas une fois l'application livrée. Etienne a montré comment Supabase utilise pgTAP pour tester en continu les politiques de base de données.
« Vous pouvez prouver que ce que vous croyez être sécurisé l'est réellement. Ces tests vous permettent de rester honnête. » - Etienne Stalmans, ingénieur sécurité chez Supabase
Chaque test vérifie ce qui importe le plus :
- Les utilisateurs publics ne voient que les données publiques.
- Les utilisateurs authentifiés ne voient que ce qui leur appartient.
- Les politiques appliquent les limites attendues à chaque fois.
Cette assurance continue garantit que les petites erreurs ne se transforment pas en fuites de données.
Une sécurité évolutive
Supabase exécute RLS pour des millions d'utilisateurs et des charges de travail importantes sans aucun problème.
« Nous l'utilisons partout, même à grande échelle. Aucun problème, aucune excuse. » - Etienne Stalmans, ingénieur sécurité chez Supabase
En renforçant la sécurité au niveau de la base de données, Supabase garantit la cohérence logique, quelle que soit la complexité de l'application.
« Faites en sorte que ça marche », une consigne dangereuse
Bill a clôturé la session en mettant en garde toute personne utilisant l'IA pour générer du code.
« Ce n'est pas parce que ça fonctionne que c'est prêt pour la production. » - Bill Harmer, CISO Supabase
« Si vous demandez à une IA de faire fonctionner quelque chose, elle pourrait supprimer les contrôles de sécurité qui vous protègent. » - Bill Harmer, CISO Supabase
Les modèles d'IA ne comprennent pas l'intention. Ils feront tout ce qui est nécessaire pour atteindre l'objectif que vous avez fixé, même si cela implique de désactiver RLS ou de supprimer la logique d'authentification.
Le danger n'est pas d'utiliser l'IA, mais de l'utiliser sans accompagnement.
« Le modèle n'est pas malveillant. Il fait son travail. Mais il ne connaît pas vos intentions. C'est votre travail. » - Bill Harmer, CISO Supabase
Construire en toute sécurité par défaut
La sécurité n'est pas un obstacle. C'est ce qui vous permet d'avancer plus vite sans remettre en question ce que vous livrez.
Supabase prouve que lorsque la sécurité réside au niveau de la couche de données, elle fait partie intégrante du processus de développement, et n'est pas une simple réflexion après coup.
Sécurisez votre logiciel dès maintenant.
.avif)
