Feature 01 / 04
Fondation
Multi-tenant par conception, pas par retrofit
Helpdash a été construit tenant-first. Chaque requête porte une frontière de workspace à la couche données ; chaque workspace possède ses lignes, son préfixe de stockage, ses rôles, son journal d'audit. Il n'existe aucun chemin — authentifié ou non — où le scope tenant est optionnel. Pour les équipes ingénierie et sécurité : c'est l'architecture que vous demanderiez en revue d'achat.
Résultats
Les garanties d'isolation qui survivent à un audit
Multi-tenant n'est pas un feature flag que nous livrons. C'est le modèle de données : scope niveau ligne sur chaque lecture et écriture, RBAC conscient de l'équipe, stockage cantonné, journal d'audit signé. Achats, SOC 2, ISO 27001 — les réponses sont les mêmes sur chaque formulaire.
Feature 02 / 04
RBAC cantonné au workspace
les rôles vivent dans un tenant, les permissions ne fuient jamais à travers la frontière
Feature 03 / 04
Préfixe de stockage par workspace avec URLs de téléchargement signées, à courte durée — pas de bucket partagé, pas de path traversal inter-tenants
Feature 04 / 04
Journal d'audit infalsifiable conservé au-delà de la suppression du workspace pour respecter les fenêtres de rétention réglementaires
À l'intérieur du modèle
Comment Helpdash rend la multi-tenancy ennuyeuse
Feature 01 / 03
Scope de requête global
Un scope global sur chaque modèle auto-filtre par clé tenant. Oublier la frontière aux sites d'appel est structurellement impossible ; le framework la câble à la couche données.
Feature 02 / 03
RBAC au niveau équipe
Rôles et permissions sont tenant-aware — le rôle d'un agent dans le workspace A est invisible dans le workspace B. Pas de transfert accidentel de privilèges entre bureaux.
Feature 03 / 03
Stockage par tenant
Les préfixes de système de fichiers (tenants/{id}/) lient chaque upload à son workspace. Les URLs de téléchargement sont signées, à courte durée et vérifiées par tenant au moment de l'émission.
FAQ
Frequently asked questions
Quel est le modèle de données ?
Un schéma unique partagé avec une clé tenant sur chaque enregistrement métier. Les modèles utilisent un trait BelongsToTenant qui installe un scope global de requête ; les lectures et écritures héritent automatiquement de la frontière workspace. L'accès inter-tenants exige un outrepassement explicite et audité à la couche application.
Comment le tenant est-il résolu à chaque requête ?
Les routes authentifiées ignorent les en-têtes X-Tenant-Slug et host — le claim workspace à l'intérieur du JWT signé fait autorité, point. Les routes non authentifiées (login, docs publiques) résolvent via en-tête → sous-domaine → query string, dans cet ordre de priorité, avec une liste de noms réservés (ex. www, api, admin) qui prévient les collisions.
Que voit réellement un auditeur ?
Un journal d'audit signé, append-only par workspace, conservé au-delà de la suppression du tenant, exportable vers votre SIEM. Plus le scope ORM : une preuve d'une ligne que chaque requête est tenant-bornée, ce qui suffit généralement pour SOC 2 CC6.1 et ISO 27001 A.9.4.1.
Voyez le modèle d'isolation dans votre propre workspace
Mettez en place deux workspaces sous une même connexion et regardez-les ne jamais se voir — à l'API, à l'UI ou à la couche stockage. Plan gratuit, pas de carte bancaire.