Sécurité et conformité
Architecture de sécurité de niveau institutionnel. Chaque contrôle est documenté, testé et auditable.
Programme Design Partner · Déployable en production · Contactez les ventes
Governance Center
510 audit entries total, 7 in the last 24 hours. Five cards link to Audit log, Compliance policy, Audit Export, Compliance dashboard, and Trust and Security mirror.
Compliance Posture
Données client isolées
Les données de chaque client sont logiquement isolées par tenant. Des politiques de row-level security Postgres appliquent le périmètre de tenant sur chaque requête — les lectures inter-tenants ne sont pas possibles depuis le code côté tenant. Votre télémétrie vous appartient seul, auditable et exportable sur demande.
Journalisation d'audit
Chaque décision, allocation et résultat est horodaté et exportable. Reporting prêt pour les investisseurs dès le premier jour. Conservation : 7 ans avec stockage immuable.
SOC 2 Type II
Audit Type II en cours. Cible : T3 2026. Posture actuelle : contrôles documentés, collecte de preuves active, auditeur tiers engagé.
Conformité RGPD
Addendum de traitement de données disponible. Droit à l'effacement, droit à la portabilité et options de résidence des données implémentés. Les données UE restent dans les régions UE.
Divulgation responsable
security@standard.online. Clé PGP disponible sur demande. Réponse garantie sous 48 heures pour les vulnérabilités critiques. Programme de primes : actif.
Traitement des données
Tous les sous-traitants ont signé des accords RGPD Art. 28 de traitement de données. La divulgation actuelle — fournisseurs, usage, classe de données, région de traitement — est fournie sous accord mutuel de confidentialité dans le cadre du DPA. Envoyez un courriel à security@standard.online avec le nom de votre firme pour la recevoir sous 24 heures.
Hash-Chained Audit Log
200 hash-chained entries with Verify hash chain action. Every event stamped policy v1.0.0.
Contrôles superposés — chaque requête traverse chacun d'eux
Standard ne s'appuie pas sur une primitive de sécurité unique. Une requête atteignant les données tenant traverse sept contrôles indépendants ; la défaillance d'un seul est contenue par le suivant.
- L0
Edge — TLS 1.3 + HSTS preload
Tout le trafic se termine en TLS 1.3 à l'edge Vercel. HSTS est défini avec max-age 2 ans, includeSubDomains et preload — le domaine est éligible aux listes preload des navigateurs, donc les attaques par downgrade sont impossibles depuis un navigateur frais.
- L1
Navigateur — CSP stricte, COOP, frame-ancestors 'none'
La Content-Security-Policy restreint script, style, frame et connect à une allowlist explicite. frame-ancestors 'none' bloque toute mise en iframe (pas de clickjacking). Cross-Origin-Opener-Policy isole les contextes de navigation. Permissions-Policy désactive caméra, micro, géolocalisation, paiement, USB et FLoC.
- L2
Auth — Clerk + MFA (TOTP / WebAuthn)
Chaque route protégée passe par le middleware Clerk avant tout code applicatif. La MFA est requise sur les comptes à scope élevé ; la passkey (WebAuthn) est le second facteur préféré.
- L3
Application — RBAC (11 rôles × 128 permissions)
L'autorisation est appliquée à la frontière de chaque procédure tRPC par un middleware requirePermission. Les rôles mappent vers des codes de permission, et chaque procédure protégée déclare quelle permission elle exige — pas d'accès implicite.
- L4
API — rate limiting par IP sur les endpoints publics
Les endpoints POST non authentifiés (inquiry système, persistance de brouillon, beacons web-vitals) sont rate-limités par IP avec headers de réponse (X-RateLimit-Limit, X-RateLimit-Remaining, X-RateLimit-Reset). Le tRPC authentifié reste derrière les quotas par compte de Clerk.
- L5
Base de données — Row-level security Postgres
Chaque table porteuse de tenant a ENABLE ROW LEVEL SECURITY avec des politiques qui filtrent par terminal.current_tenant_id(). Le code côté tenant ne peut pas lire au travers des tenants. L'accès administratif passe par un helper withStaffScope() explicite et journalisé en audit qui ne contourne la RLS qu'après avoir enregistré l'appel.
- L6
Réseau — TLS managé vers Postgres + egress journalisé
Les connexions base de données sont TLS-only via le Postgres managé Neon. Allowlist IP et VPC peering sont disponibles pour les déploiements Sovereign. Les appels d'intégration sortants sont médiatisés par un connecteur à seau de jetons qui journalise chaque appel ; aucune intégration ne tourne sans mesure.
Chaque couche est testée indépendamment. Tests d'intrusion, intégrité du log (audit log à chaîne de hash), et procédures de réponse aux incidents sont décrits dans la Politique de confidentialité et la documentation Confiance.