Registre Listrar
Sécurité
Cette page décrit des contrôles qui existent aujourd'hui dans le produit. Lorsqu'un élément relève d'une configuration de déploiement plutôt que d'un contrôle implémenté, il est présenté comme tel.
Isolation des locataires, en deux couches indépendantes
Chaque requête métier est limitée au locataire appelant au niveau de la couche d'accès aux données, de sorte qu'un accès inter-locataires ne peut pas survenir par omission. En dessous, la sécurité au niveau des lignes de PostgreSQL est appliquée à chaque requête via des variables de session, offrant un garde-fou imposé par la base qui ne dépend pas de la justesse du code applicatif. Les deux couches doivent échouer pour qu'une donnée franchisse une frontière de locataire.
Le rail public
Les visiteurs anonymes accèdent aux passeports produits via un client qui ne définit aucun locataire, ce qui restreint chaque lecture aux politiques de lecture publique : produits publiés et leurs relations. Le filtre applicatif demeure, mais il n'est plus le seul rempart entre un visiteur et les brouillons d'un autre locataire.
Autorisation par capacités
Les permissions sont exprimées en capacités, non par comparaison de noms de rôles, et un seul registre alimente la navigation du tableau de bord, les gardes de page et les vérifications côté serveur — elles ne peuvent donc pas diverger. Refus par défaut. Modifier le statut d'un enregistrement et consigner une vérification sont des capacités distinctes de l'édition du catalogue, parce que ce sont des actes différents.
Piste d'audit
Les événements pertinents pour la sécurité — connexion et déconnexion, chaque création et modification de produit, chaque changement de statut, chaque vérification créée ou révoquée — sont inscrits dans un journal en ajout seul. L'ajout seul est imposé par le code, non par convention : les chemins de mise à jour et de suppression ne sont pas disponibles sur cette table.
Authentification de l'API
Les clés d'API ne sont stockées que sous forme de condensats, jamais en clair. Chaque clé porte des portées explicites, et une route refuse une clé dépourvue de la portée requise. Les requêtes sont décomptées d'un quota mensuel par clé selon le palier. Les entrées sont validées à chaque frontière avant d'atteindre la base.
Où les données sont hébergées
Le déploiement fixe une région de l'UE pour l'hébergement et la base de données, et la documentation de conformité du projet consigne la résidence des données dans l'UE comme posture de conception. Il s'agit d'un choix de configuration inscrit dans le dépôt, non d'une certification indépendante, et cette page ne prétend pas le contraire.