Sécurité & auditabilité

Conçu pour l’examen.

TrustStack est conçu pour l’examen des PSP, des banques, des partenaires et des réviseurs autorisés. Cette page énonce des contrôles cibles et des questions de validation ; une surface ui/lecture enregistrée n’établit pas une application complète en production. Statut du registre →

Posture cible : classer les données de production du périmètre en Restricted, minimiser les PII, tenir les secrets hors des logs de décision et utiliser des ID de corrélation. Confirmer les preuves d’implémentation pendant la due diligence.
Défense en profondeur · à valider

Isolation des tenants

  • Le design cible porte le contexte tenant à travers middleware, authentification et politique de service
  • Les données du tenant sont conçues autour de tenant_id avec des contrôles au niveau des lignes pour les jeux de données sensibles
  • La séparation inter-tenants doit être testée sur requêtes, exports, logs, preuves et vues opérateur
  • Les tests d’accès négatifs et le comportement des alertes font partie du périmètre de validation convenu
Jeu de contrôles cible

Baseline de sécurité

  • Moindre privilège, séparation des tâches et identifiants à courte durée de vie sont des exigences de design
  • Les procédures de gestion et de rotation des secrets sont vérifiées pour l’environnement délimité
  • L’authentification de service et les chemins de données privés sont validés avant tout usage en production
  • Scans CI/CD, contrôles de dépendances et traçabilité des releases restent des contrôles soumis à preuve
À finalité délimitée

Intégrité des preuves

  • Les producteurs configurés devraient émettre acteur, heure, motif et contexte de corrélation pour les décisions significatives
  • Le design prend en charge des enregistrements orientés append et la vérification par hachage ; le mode de stockage dépend de l’environnement
  • Des packs de preuves délimités peuvent inclure chronologies enregistrées, références de sources, versions de règles, notes et pièces jointes
  • La rétention, les dérogations par juridiction et les legal holds exigent une validation du workflow et du contrat
Maker-checker configuré

Gouvernance & contrôle des changements

  • Une approbation distincte peut être exigée pour des changements sensibles configurés : règles, seuils, routage, packs de politiques
  • Des versions de politiques enregistrées peuvent garder les décisions historiques explicables lorsque le producteur les fournit
  • Revues d’accès, journaux d’actions opérateur et échantillonnage QA sont des activités de contrôle délimitées
  • Les exports de due diligence sont à finalité délimitée et revus pour complétude avant toute utilisation externe

L’examen commence par des frontières inspectables.

La proposition est un schéma de contrôle connecté : contexte de décision explicite, preuves délimitées, règles versionnées, frontières de tenant et revue gouvernée — chaque élément testé pour la finalité convenue.

Prêt à regarder sous le capot ?

Un pack de due diligence à jour peut être délimité sous NDA au parcours et à l’environnement proposés. Les artefacts d’implémentation disponibles, matrices de décision, preuves d’isolation, conditions ouvertes et feuille de route sont confirmés pendant la revue — pas présumés depuis cette page.

Cette page résume des intentions de contrôle ; le périmètre final est validé pendant la due diligence et le cadrage du pilote. Il s’agit d’une information générale, pas d’un conseil juridique.