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, une couche de contrôle d'accès indépendante, imposée par la base de données, applique la même restriction à chaque requête — un garde-fou 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 par une voie d'accès qui ne porte aucun contexte de locataire, ce qui restreint chaque lecture aux seuls produits publiés et à leurs relations publiques. Le filtre applicatif réservé au contenu publié demeure en place — il n'est plus le seul rempart entre un visiteur et les brouillons d'un autre locataire.
Contrôle d'accès
Les permissions suivent des règles de moindre privilège et de refus par défaut : rien n'est autorisé sans avoir été explicitement accordé, et le même ensemble de règles régit ce qu'un utilisateur voit dans le produit, ce qu'une page autorise et ce que le serveur accepte en définitive — ces trois éléments ne peuvent donc pas diverger. Modifier le statut d'un enregistrement et consigner une vérification sont des permissions 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 conservés dans une piste d'audit conçue pour garantir la traçabilité et faciliter les investigations. Les entrées ne peuvent être ni modifiées ni supprimées après coup.
Sécurité de l'API
L'accès à l'API est authentifié et limité par portées : chaque clé porte des permissions explicites, et une requête est refusée si la clé ne dispose pas de la portée requise. L'usage est mesuré contre un quota, et les identifiants sont gérés selon des pratiques conçues pour empêcher l'exposition d'un secret réutilisable. Chaque entrée est validée avant d'atteindre le stockage.
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 de déploiement, non d'une certification indépendante, et cette page ne prétend pas le contraire.